네트워크(3) - TCP

오늘도 이전 포스팅에 이어 네트워크 글입니다!

 

TCP의 중요 기능을 정리해 보겠습니다.

 

 첫 번째 흐름 제어 즉, flow control은 send buffer가 receive buffer에게 받을 수 있는 만큼만 보내주는 기능입니다.

 만약 receive buffer가 반만 받을 수 있는데 send buffer가 가득 준다고 하더라도 받을 수 없습니다. 그렇다면 send buffer는 상대방의 receive buffer의 사용 가능한 공간을 어떻게 알 수 있을까요? 그건 저번 포스팅의 TCP header에 window size를 통해 사용 가능한 공간을 send buffer에게 알려주기 때문에 알 수 있습니다. 이 과정에서 receive buffer가 받을 공간이 없다면 header에 0이 담겨 갈 것입니다. 그리고 send buffer는 받을 공간이 0이니 응답을 보내지 않을 경우 연결이 끊기게 됩니다.(why? sender buffer는 receive buffer의 상황을 실시간으로 알 수 없기 때문에) 이런 상황을 막기 위해서 receive buffer가 자신의 상태를 계속 알릴 수 있도록 sender buffer는 주기적으로 1(상징적으로 1이라고 표현했지만 연결을 유지하기 위한 용도)을 보내 응답을 기다리게 됩니다.(receive buffer의 사용 가능한 공간이 생기면 처리할 수 있도록.)

 

생각의 확장

 위의 이미지는 하나의 segment가 아닌 많은 segment들이 있다고 상기하기 위해 첨부한 것입니다. 위와 같이 공부하더라도 실제에서는 확장해서 생각을 하는 습관을 가져야 할 것 같습니다!(여담~)

 

3-way-handshake

 두 번째 3-way-handshake는 위의 이미지처럼 client - server의 연결을 하는 것이고, 위에서 보았던 흐름 제어에 본 클라이언트와 서버의 버퍼를 만들어주는 과정입니다. TCP의 header에 이미지와 같은 데이터를 담아보내며 3번째 마지막 client의 ACK를 끝으로 버퍼를 만들게 됩니다. 이 3-way-handshake는 TCP의 연결 방식에서만 쓰이는 것이 아니라 범용적으로 사용되는 방식인 것 같습니다. 대표적인 예는 저희가 그나마 친숙한 HTTP입니다.

 

HTTP의 3-way-handshake

 위의 이미지는 HTTP일 경우 3번째에 ACK와 요청을 보내며 데이터를 담아 보내게 됩니다. 

 

Closing TCP Connection

 오늘 포스팅의 마지막 세 번째 기능 client - server가 close 할 때입니다. 연결을 종료하기 위해 client는 FIN(자신의 데이터를 다 보내는 것)을 server에게 보내고 서버는 ACK를 보내고 server 측에서 보내지 못한 데이터를 보낸 후 client와 마찬가지로 FIN을 보내주고, ACK를 받습니다. Timed wait은 버퍼들을 ACK를 보낸 후 바로 없애는 것이 아니라 긴장상태로 일단은 유지를 시켜놓는다는 뜻입니다. 이유는 마지막 ACK가 유실되었다고 가정하면 server는 아마 timeout이 터지며 다시 FIN을 보낼 것입니다. 하지만 Timed wait이 없다면 이미 client 모든 것이 철수한 뒤고 server는 홀로 데이터를 보내지만 받을 수 없는 상태가 되기 때문에 이런 상황을 방지하기 위해 일정 시간 동안 철수하지 않고 기다려 위의 상황을 방지해 줍니다. 

 

 이 내용은 kocw의 이석복 교수님의 네트워크 강의를 듣고 공부한 내용입니다.

컴퓨터네트워크