[네트워크] TCP 흐름 제어, 3-way handshake, 4-way handshake

네트워크 관련 글 순서(참조 영상 기준)

애플리케이션 계층
- 네트워크 애플리케이션의 원리
- DNS
- TCP를 이용한 Socket 프로그래밍

전송계층
- 전송 계층 서비스의 원리
- rdt 원리
- 연결 지향 전송: TCP
- TCP 흐름 제어(3-way handshake, 4-way handshake)
- TCP 혼잡 제어

네트워크 계층
- 네트워크 계층 서비스
- Network Address Translation(NAT), DHCP
- 라우팅 알고리즘(Link State, Distance Vector)
- 계층적 경로 변경(AS)

링크 계층
- 다중 엑세스 프로토콜
- LANs(근거리 통신망)

무선 및 모바일 네트워크
- 무선 네트워크

웹 요청 시 일어나는일

네트워크 보안
- 대칭키 & 공개키,RSA 암호화
- Secure e-mail, SSL, MAC
- IPSec(ESP), Firewall(방화벽)

 

TCP flow control(흐름제어)

reciver의 버퍼의 크기와 남은 공간을 보고, window size와 데이터를 보낼지 말지 정하는것.

 

1) stop and wait

매번 전송한 패킷에 대한 피드백을 받아야 다음 패킷 전송하는 방식.

한개씩의 세그먼트를 보내기 때문에 비효율적.

 

2) Sliding Window

window만큼의 데이터를 보내고, 피드백을 받는 방식.

 

송신측에서 데이터를 계속 보내는데, 수신측의 애플리케이션에서 읽는 속도가 느리다면 데이터가 들어와도 RCV에 못 저장해둔다.

그렇기 때문에 이 보내는 흐름^[각주:1]을 제어할 필요가 있는데, 버퍼의 남아있는 크기를 알려줘서 송신측에서 보내는 것을 조절한다. 이 정보는 세그먼트 헤더에 들어가있다.

 

윈도우 사이즈도 수신측의 버퍼크기에 따라 달라진다.(한번에 보내는 데이터 양이 RCV buffer보다 크면 안되므로)

 

근데 이방법도 문제가 하나 있다.

만약 버퍼에 공간이 없다고 알려줘서 더 이상 송신측에서 데이터를 안 보낼때 수신측에서 추후 데이터 공간이 생기면 이걸 송신측에 알려줘야한다.

 

이걸 알려줄 수 있는 방법은 결국 세그먼트를 보내야하는건데,

수신측에선 송신측에 보낼 데이터가 없다고 가정하면 송신측에선 버퍼가 꽉찼다고 생각하기때문에 더이상 데이터가 안와서 피드백 보낼일도 없다.

 

그래서 이 경우를 해결한 방법이 수신측에서 꽉 찾다고 알려줬을때, 송신측에선 아주 조그마한 세그먼트를 날려서 수시로 수신측 RCV 버퍼의 공간을 체크한다.(Probe Segment: 1 byte data를 보냄)

(헤더 40byte 데이터 1byte의 이상한 형태의 세그먼트가 날라감)

 

그럼 돌아오는 피드백을 통해 버퍼에 공간이 얼마나 남았는지 확인이 가능하다.

 

 

TCP 흐름제어 기술

 

한 세그먼트의 사이즈가 크면 중복 데이터를 줄일 수 있다.

(헤더는 40byte로 고정되니 여러번 보내는것보다 적게 보내는게 좋음. 오버헤드가 적어짐)

 

대신 애플리케이션에서 send buffer에 데이터를 내리는게 아주 늦다면, 세그먼트 사이즈가 찰때까지 기다려야해서 느려진다.

 

 

그래서 tcp는 첫번째 세그먼트는 어느정도 양이든 무조건 보낸다.

그럼 해당하는 피드백이 오는 사이에 데이터가 쌓일테고, 이 데이터가 세그먼트의 최대 크기를 채웟다면 피드백이 오기전에 보내고, 안쌓였다면 피드백이 도착하면 그만큼을 보낸다.

 

또 하나의 합리적인 방법을 채택하고 있는데,

rcv에서 0이 아니라 조그마한 공간이 있을때도 0으로 보내는데 그 이유는

1byte의 공간만 남았을때 1byte의 공간만큼 데이터를 받는거는 비효율적이다.. 그렇기때문에 그냥 꽉 찼다고 알려주고 버퍼공간을 좀 비운뒤에 받을 수 있게 한다. 

 

2) delayed ack

피드백을 바로바로 해주는게 아니라, 좀 일정시간 뒤에 해주는 방법이다.

이렇게 하면, 연달아서 데이터가 채워졌을경우 피드백을 여러개 보낼 필요없이 채워진 만큼의 뒤의 피드백을 보내면 되기 때문에 좋다.(정보통신량을 줄일 수 있음)

 

TCP Connection(3-way handshake)

위와 같은 데이터 통신이 이루어지기 전에, 

TCP는 3-way handshake에 의해 연결이 이루어진다.

 

 

tcp SYN 이라는 데이터를 보내서 연결하자고 요청

(헤더로만 이루어져 있고, 여기엔 SYN Bit가 있음)

그럼 상대방측에선 SYN Ack 피드백을 보내줌

그럼 연결요청측에서 다시 일반적인 Ack를 보내면서 잘 연결된것을 알려줌.(근데 이땐 일반적인 세그먼트형태여서 보내고자하는 데이터를 같이 보낼 수 있음)

 

 

TCP closing(4-way handshake)

 

연결을 끊을때도 비슷하다.

연결을 끊겠다는 FIN을 보낸다(개발자가 정함 SOCKET.close())

그럼 수신측은 그에 해당 하는 ack를 보내고, 수신측이 남은 데이터를 다 보낸 후 송신측에 FIN을 보내고 다시 송신에서도 그에 해당하는 ack를 보낸다.

 

처음 연결을 끊자고한 곳에서 FIN에 대한 ACK를 받고, 상대방의 FIN을 받았어도 바로 버퍼를 지우진 않는다.(TIME_WAIT 시간만큼 기다림)

이유는 마지막으로 보낸 ACK가 유실되었을 경우 상대측에선 계속 fin을 보내게되기때문에 지우지 않는다.

 

이렇게 4번의 통신이 다 끝나면 연결이 해제된다.

---

참조

 

KOCW 네트워크 강의 - 한양대 2018 1학기 이석복 교수님

컴퓨터네트워크

 

1. 데이터를 주고 받는 흐름 [본문으로]