3-4-2. TCP : Connection-oriented transport(3)

 

Flow Control

 

receiver의 buffer에서 일어나는 일이기 때문에 receiver 입장에서 보면 된다. 

 

TCP는 IP로부터 받은 데이터를 application 계층에 올려보내기 전에 receiver buffer에 일단 저장

application 계층은 그 transport 계층의 버퍼에서 읽어감

=> application 계층이 읽어가는 속도보다 transport 계층 buffer에 들어오는 속도가 빠르면 overflow 발생

=> flow control을 통해 해결

 

 

 

TCP socket receiving buffer는 운영체제가 지정(보통 4096 bytes)

receiver가 sender에게 ACK을 보낼 때, ACK의 receive window에 이 buffer의 용량(rwnd)을 적어서 보내줌

=> sender는 그 용량을 넘지 않도록 receiver의 buffer에 밀어넣는다.

 

 

Connection Management: 3-way handshaking

 

TCP는 연결지향형 프로토콜이기 때문에 handshaking이 진행된다.

 

사람과 사람이 대화할 때는, 대화를 요청하면 수락하면서 단순한 대화 연결이 가능하다.

하지만 client와 server 간 TCP 연결은 고려 사항이 너무 많아 2-way handshaking으로는 부족하다.

 

2-way hankshaking의 문제점(server는 timeout되면 이전 정보 잊어버림 !!)

1. client가 retransmit했던 connection 요청이 server가 정보 잊어버린 다음에 server에 도착 => server 혼자 처량히 기다림..

 

2. client가 retransmit했던 데이터가 server가 정보 잊은 다음 server에 도착 => 데이터가 반영돼버려 다음 작업에 오류

 

 

connection의 parameter(buffer size, 시작 seq# 등)들을 server와 client가 협상하게 된다. 

 

 

=> 즉 2-way밖에 없다면 server측에서 문제가 발생할 수 있다 !!

 

3-way handshaking

 

(handshaking 1) client->server: SYNbit와 seq# 보냄 => server는 LISTEN 상태

SYNbit=1, seq#=x

(handshaking 2) server->client: ACK 보냄 => server는 SYN RCVD 상태

SYNbit=1, seq#=y, ACKbit=1, ACK#=x+1

(handshaking 3) client->server: server가 보낸 ACK에 대한 ACK 보냄

ACKbit=1, ACK#=y+1

 

 

TCP connection 끊기

 

client와 server 각각 connection 끊을 때는 독립적으로 작용한다.

 

 

각 화살표를 1, 2, 3, 4번으로 번호 매기고 각 번호 별로 정리해봤다.

(1,2 => client의 connection 끊기

3,4 => server의 connection 끊기)

 

(client 입장)

1. x번 seq#를 끝으로 한다는 FINbit 를 보냄(FINbit=1, seq#=x) => 이제 더이상 server로 내보낼 것이 없다는 FIN_WAIT_1 상태로 변환

**2번이 끝나면 server의 final segment 오기를 기다리는 FIN_WAIT_2상태로 변환

4. server가 보낸 FIN segment에 대한 ACK 내보냄(ACKbit=1, ACK#=y+1) => 혹시라도 내가 보낸 ACK이 server로 가던 도중 loss돼서 server가 FIN ACK 요청 retransmit할 경우를 대비해 시간 길게 열어놓는 TIMED_WAIT상태로 변환

 

(server 입장)

2. client가 보낸 FIN segment에 대한 ACK 내보냄(ACKbit=1, ACK#=x+1) => 이제 더이상 client로 받을 것이 없다는 CLOSE_WAIT 상태로 변환(하지만 client로 보낼 수는 있음 -> 당연함. 클라이언트에게 FINbit 보내야 함) 

3. y번 seq#를 끝으로 한다는 FINbit 를 보냄(FINbit=1, seq=y) => 이제 server도 client로 내보낼 것이 없는 LAST_ACK 상태로 변환

 

 

**4번 이후 server 먼저 CLOSED => client는 TIMED_WAIT 상태가 끝나면 CLOSED