6주차 정리

TCP의 상태 전이도-FSM)

rdt 1.0: 만약 네트워크 계층이 신뢰도를 보장해준다면 전송 계층은 패킷을 전송 및 수신만 하면 될것이다.

rdt 2.0: 정상적으로 수신 했다는 ACKs 패킷을 전송, 패킷에 에러가 있으면 NAKs 패킷 전송, 그러나 ACK와 NAK 패킷에 문제가 있을 수 도 있다.

rdt 2.1: 송신측에서 패킷에 시퀀스 번호를 추가해서 전송한다. 복제된 패킷인지 아닌지 판단 가능. 복제된 패킷이면 버린다.

rdt 3.0: 복잡한 패킷 에러를 처리가능, 패킷유실에 대응하기 위해서 timeout을 추가한다. timeout이 너무 길면 오버헤드는 낮지만 패킷유실에 제대로 대응이 안되고, timeout이 짧으면 오버헤드가 높지만 패킷유실에 빠르게 대응할 수 있다. 

 

참고: https://dev-nicitis.tistory.com/27

3-2. 전송(Transport) 계층: 신뢰성 있는 데이터 전송(RDT)

 

 

TCP 에러 문제 해결책)

1. 데이터의 왜곡(Bit Errors) 점검 및 해결 - Checksum, ACK/NAK

2. 패킷(Data & ACK) 손실 문제 해결 - Timer 설정(Time Out), Sequence Number 설정 -> 순서 및 중복 전송 해결

3. 윈도우(버퍼) 또한 필요 - 크기 변동이 가능, 송신자와 수신자의 윈도우 사이즈는 다를 수 있다, 처리율에 영향을 미침

 

Packet 재전송)

Stop & Wait - 하나 보내고 답장 오면 하나 보내는 방식(실제로 잘 안씀)

Pipelining Method

1. Go-back-N : 실패한 패킷 부터 다시 전부 새로 보냄, 마지막으로 받은 패킷에 대한 ack를 계속 보낸다, 슬라이딩 윈도우 사용.
2. Selective Repeat: 실패한 패킷만 다시 보냄(받은 패킷을 buffer에 저장한다.), 패킷별로 타이머 작동.

TCP는 실제로 위 방법을 혼합해서 사용

 

TCP Segment Structure)

 

 

 

 

TCP Timer - RTT)

 

TCP 타이머 중 하나인 RTT(Round Trip Time) 타이머는 데이터를 전송한 후 응답을 받을 때까지 걸리는 시간을 측정. TCP는 안정적으로 데이터를 송신 할 수 있다. RTT 타이머는 TCP의 송신 측에서 유지된다. RTT 타이머 값은 TCP의 재전송과 윈도우 크기 조절 등에 사용된다.

1. 재전송 타이머: 데이터 전송 후 응답을 받지 못한 경우, 송신 측은 재전송 타이머를 설정하여 일정 시간 이내에 응답이 없으면 데이터를 다시 전송. 이때, 재전송 타이머는 RTT 타이머 값을 기반으로 설정.
2. 윈도우 크기 조절: TCP는 RTT 타이머 값을 기반으로 수신측이 버퍼를 비우는 속도에 맞추어 송신 윈도우 크기를 동적으로 조절. 이를 통해 네트워크 혼잡을 방지하고 안정적인 데이터 전송을 수행.
3. 흐름 제어: RTT 타이머 값을 기반으로 TCP는 데이터 전송 속도를 제어. RTT 값이 증가하면 전송 속도를 감소시켜 데이터 유실을 방지하며, RTT 값이 감소하면 전송 속도를 증가시켜 데이터 전송량을 높인다.

 

TCP의 신뢰성 있는 전송 방법)

1. 응용층의 데이터를 받으면. 세그먼트를 만들면서 시퀀스 번호를 부여 한다.

2. 패킷을 보낸 후에 타이머를 설정한다.

3. 타이머가 종료되면(ACK를 받지 못하면) 패킷을 재전송 및 타이머를 설정한다.

4. ACK를 받으면 윈도우에 ACK 번호 재설정

5. 수신자가 데이터를 받으면 비트 에러 체크 -> 에러 발생시 NAK, 시퀀스 번호를 검사하여 문제가 없으면

누적 ACK를 보낸다, 패킷 중복시 버림

 

TCP 흐름제어(Flow Control))

 

TCP 흐름제어에서는 수신측에서 수신 가능한 윈도우(버퍼)의 크기를 송신측에게 알려줌.

이 윈도우의 크기는 송신측이 수신측에게 전송할 수 있는 데이터 양을 제한.

즉, 송신측은 수신측으로부터 받은 윈도우의 크기를 고려하여 데이터를 전송.

 

예를 들어, 수신측에서는 현재 100바이트까지 수신할 수 있는 윈도우 크기를 알려준 경우, 송신측은 이에 따라 100바이트 이하의 데이터만을 전송. 만약 송신측이 200바이트의 데이터를 전송하고자 하지만, 수신측으로부터 100바이트까지만 전송 가능하다는 윈도우 크기를 받은 경우, 송신측은 100바이트만 전송하고, 이후 데이터 전송은 윈도우 크기에 따라 조절.

 

이러한 TCP 흐름제어는 데이터의 손실을 방지하고, 전송 지연을 최소화하여 네트워크의 성능을 향상시키는 역할을 한다.

•TCP 송신 윈도우 크기 : 수신측으로부터 확인응답없이 전송할 수 있는 데이터의 크기

 

TCP에서 2-way handshake 사용시 문제점)

TCP에서 연결 설정을 위해 사용되는 2-way handshake는 클라이언트와 서버 간의 연결 상태를 파악하는 데에만 사용.

이 과정에서 서버는 SYN 패킷을 받았을 때, 클라이언트가 여전히 살아있는지, 응답할 수 있는 상태인지 등을 확인할 수 있다.

하지만 2-way handshake는 클라이언트가 SYN 패킷을 보낸 후, 서버가 ACK와 SYN 패킷을 보낸 다음에는 클라이언트로부터 ACK 패킷이 도착하기를 기다리지 않는다. 이로 인해 클라이언트가 ACK 패킷을 보내지 않거나, ACK 패킷이 분실되는 경우, 서버는 이를 확인할 수 없다.

만약 이러한 상황이 발생하면, 서버는 일정 시간동안 대기한 후에 연결 설정 실패로 간주하고 연결을 종료함. 이는 불안정한 연결 설정 상태를 초래할 수 있으며, 이러한 문제를 해결하기 위해 3-way handshake가 사용된다.

 

TCP의 3-way handshake - 연결)

 

 

TCP는 처음에는 3-way handshake를 통해 연결을 설정.

3-way handshake는 클라이언트가 SYN 패킷을 보내고, 서버가 SYN-ACK 패킷을 보내며, 클라이언트가 ACK 패킷을 보내는 과정.

ex) 사용자가 웹페이지에 www.naver.com을 입력하면 브라우저는 DNS 서버에게 www.naver.com의 IP 주소를 요청. DNS 서버는 해당 도메인의 IP 주소를 반환. 이후, 브라우저는 해당 IP 주소와 TCP 연결을 시도.

3-way handshake는 TCP 연결을 설정할 때 발생. 따라서, 브라우저는 www.naver.com의 IP 주소와 3-way handshake를 통해 TCP 연결을 설정. 이 때, 브라우저는 SYN 패킷을 보내고, 서버는 SYN+ACK 패킷을 보내고, 브라우저는 ACK 패킷을 보내서 3-way handshake가 완료됨.

 

 

 

TCP의 4-way handshake - 종료)

연결을 종료하기 위해 4-way handshake를 사용

4-way handshake는 클라이언트가 FIN 패킷을 보내고, 서버가 ACK 패킷을 보내며, 서버가 FIN 패킷을 보내고, 클라이언트가 ACK 패킷을 보내는 과정.

ex)

이후, 브라우저는 HTTP 요청 메시지를 서버에게 보냄. 서버는 요청에 대한 응답으로 HTTP 응답 메시지를 보냄. 이 때, TCP 연결이 종료되는 4-way handshake는 HTTP 응답 메시지를 모두 전송한 후 발생. 브라우저는 FIN 패킷을 보내고, 서버는 ACK 패킷을 보낸다. 그리고 서버가 보낸 데이터를 모두 받았다는 의미로 더 이상 데이터가 없다는 뜻을 담은 FIN 패킷을 보낸다. 마지막으로, 브라우저는 ACK 패킷을 보내서 4-way handshake가 완료.

 

다양한 TCP Variants 발전 과정 및 역사)

1. TCP Tahoe: 초기의 TCP 구현 방식 중 하나로, Congestion Control 방식 중 Slow Start와 Congestion Avoidance을 사용.
2. TCP Reno: Tahoe를 개선하여 Congestion Control 기능이 개선. Congestion Window가 어느 정도 축소된 후에 Slow Start가 실행.
3. TCP NewReno: TCP Reno의 개선 버전으로, Fast Recovery와 Fast Retransmit 기능을 추가. 또한, DupACK Threshold 기능이 개선되어 재전송 대기 시간이 단축.
4. TCP Vegas: 패킷 전송 속도를 평가하여 Congestion을 감지하는 방식을 사용. Tahoe나 Reno와 달리 응답 시간(RTT)을 고려.
5. TCP SACK (Selective Acknowledgement): 재전송 시 전체 패킷을 재전송하는 대신, 분실된 패킷만 재전송하는 방식으로 전송 성능을 개선.
6. TCP CUBIC: 현재 가장 많이 사용되는 TCP Variants 중 하나로, Congestion Window를 큐브 함수로 계산하여 Congestion Control을 수행. 일반적인 Slow Start 보다 더 빠르게 패킷을 전송할 수 있다.
7. TCP BBR (Bottleneck Bandwidth and RTT): 구글에서 개발한 TCP Variants로, 네트워크 대역폭과 RTT를 고려하여 Congestion Control을 수행. 현재 가장 빠른 전송 속도를 보인다.

 

TCP 혼잡 제어)

TCP 혼잡 제어(congestion control)는 네트워크의 혼잡 상태를 감지하고, 네트워크를 과도하게 사용하지 않도록 송신 측의 전송 속도를 제어하는 기능.

End to End: 네트워크 피드백에 상관없이 end systemd의 tcp에서 해결하는 방식

 

<혼잡 제어 알고리즘>

AIMD 방식:

공통: 1개, 2개, 3개 점진적으로 늘려가면서 패킷을 보냄

Addaptive Increase: 손실 발생하는 경우 0으로 낮춘후 다시 처음 개수 부터 시작

Multipicative Decrease: 손실 발생하는 경우 개수를 절반으로 낮춘 후 시작

 

Slow Start:

TCP 연결 시작 시 초기에 송신 윈도우 크기를 작게 설정하고, 성공적으로 전송된 패킷 수에 따라 윈도우 크기를 지수적으로 증가시켜 전송 속도를 빠르게 증가시키는 알고리즘. 초기에는 네트워크 혼잡도를 파악하지 못하므로 작은 윈도우 크기에서 시작하여 혼잡이 발생하기 전까지 윈도우 크기를 지수적으로 증가시킨다.

 

Congestion Avoidance:

Slow Start 이후에, 혼잡 발생을 피하기 위해 전송 속도를 조절하는 알고리즘. Slow Start과 달리, 윈도우 크기를 지수적으로 증가시키는 대신, 패킷 손실이 발생할 때마다 윈도우 크기를 감소시켜 혼잡을 피한다.

 

 

Fast Recovery:

Congestion Avoidance과 유사하지만, 패킷 손실이 발생했을 때, 전송 속도를 감소시키는 대신에, 윈도우 크기를 유지한 채, 중복된 ACK를 받으면 패킷 손실이 발생하지 않은 것으로 간주, 윈도우 크기를 증가시키는 알고리즘. 이는 패킷 손실이 가상적으로 발생했을 때와 실제 패킷 손실을 구별하지 못하므로, 혼잡 제어를 위해 Congestion Avoidance으로 전환된다.

 

참고: https://mindnet.tistory.com/entry/네트워크-쉽게-이해하기-22편-TCP-3-WayHandshake-4-WayHandshake