UDP와 검사합(checksum)
UDP 서비스
URL : 80%(port number로 이미 정해져있고.) + 20% (IP 주소)
UDP는 TCP보다 하는 게 없다!
연결 설정을 해줄 필요 없어. (출발-도착 사이에 신뢰 연결을 위한 과정이 없다.)
따라서, application process랑 transport계층 사이에는 목적지 지정 송신, 출발지 지정 수신이라는 두 정보가 전해져야 한다.
-
Datagram 실시간 전송 서비스
- application process로부터 data가 송신 socket에 전달되면, 송신 UDP는 해당 data를 포함하는 datagram 생성- 각 datagram을 IP를 통해 독립적으로 목적지 UDP socket에 전송
-
응용
- 인터넷 전화 등 실시간 응용에 적합- DNS 등 작은 data, 빠른 응답 지연 시간이 요구되는 응용에 적합
-
1:N datagram 통신 서비스
- 목적지 IP주소에 multicast address를 사용하여, 다수의 목적지 socket으로 datagram 전송 가능- 여러 개의 socket으로부터 datagram 수신 가능
- application process를 송신할 때마다, UDP에게 수신 socket address 지정
- UDP가 application process에게 data를 전달할 때마다, 송신 socket address 표시
-
응용
- IPTV 등 multicast 응용 효과적 지원
UDP datagram structure
UDP에서 전송할 data의 단위를 datagram이라고 함.
(TCP에서 전송할 data의 단위는 segment라고 함.)
checksum :: 무결성 확인
--> Intergerity (Hash function 중 가장 간단한 방식인 checksum!)
-
송신자
- 송신하는 메세지를 정해진 길이의 data 단위로 나눔- 모든 data 단위를 1의 보수 연산으로 더해서 합을 구함
- 합의 1의 보수를 checksum으로 생성하고, checksum을 추가하여 메세지 전송
-
수신자
- 수신된 메세지(datagram)를 정해진 길이의 데이터 단위로 나눔- 모든 데이터 단위를 1의 보수 연산으로 더하여 합을 구해
- 합이 0이면 성공적 수신, 아니면 err(폐기)
장점
- 높은 오류 검출 능력
- 단순함
- software 구현에 적합
단점
- 각 data 단위에서 발생하는 error의 합이 0이 되는 경우, 오류 검출 불가
- checkksum을 변경하지 않는 오류 검출 불가
논설 내용 복습
이 밑은 개인 공부
UDP - checksum 제공해줌 (ent-end priciple을 지키기 위해)
: UDP는 최소한의 안전 장치로 checksum을 제공한다.
: checksum은 송수신 과정에서 데이터 손상 검증을 안 하는 경우가 잇어서 제공함.
(end-end-principle에 따르면, 종단에서 처리하는게 더 효율적이기 때문에 그렇다!)
rdt(reliable data trans)
rdt1.0 : 신뢰전송 :: 송수신 측 둘 다 신뢰전송, 문제 없음.
rdt2.0 : 송신측에서 보낸 정보가 중도에 누락된 경우, 수신측에서 ACK, NAK을 반환해줘서, 이에 따라 수신측에서 작업을 확정지음. ::> 문제) ACK, NAK가 손실/누락 되면, 송신 측이 이를 알 수 없다.
rdt2.1 : 시퀀스 번호(0과 1)를 추가하여 재전송된 패킷인지, 정상적인 새로운 패킷인지 구분할 수 있도록 했습니다. 송신 측은 패킷을 전송할 때 시퀀스 번호를 포함하며, 수신 측도 ACK와 NAK에 시퀀스 번호를 포함시켜 응답합니다.
- NAK 손실 문제 해결: 만약 수신 측이 손상된 패킷을 수신하고 NAK가 손실되었더라도, 송신 측이 이전 시퀀스 번호의 ACK를 수신하면 해당 패킷을 재전송하여 오류를 해결할 수 있습니다.
rdt2.1은 이러한 문제를 해결하기 위해 시퀀스 번호를 도입했습니다.
시퀀스 번호 (0과 1)를 각 패킷에 포함하여 송신 측과 수신 측이 패킷의 순서를 추적할 수 있습니다.
수신 측이 중복된 ACK를 보내거나 중복된 시퀀스 번호를 감지하면 송신 측은 오류를 인식하고 재전송을 수행할 수 있습니다.
rdt2.2 : NAK이 문제가 생기니, 그냥 NAK를 없애버리자~ 대신 중복된 ACK의 경우, 오류를 송신 측에 알리자.
중복 ACK를 통한 오류 감지:
수신 측이 손상된 데이터 패킷을 수신하면, NAK를 보내는 대신 마지막으로 올바르게 수신한 데이터 패킷의 ACK를 다시 보냅니다.
송신 측은 이러한 중복 ACK를 수신하면, 오류가 발생했음을 인식하고 해당 패킷을 재전송합니다.
시퀀스 번호 사용 (0과 1):
시퀀스 번호를 사용하여 송신 측과 수신 측이 각 패킷의 순서와 중복 여부를 추적할 수 있습니다.
송신 측은 각 패킷에 시퀀스 번호를 포함시켜 보내고, 수신 측은 해당 시퀀스 번호에 대한 ACK를 반환합니다.
중복 ACK를 통해 송신 측은 해당 패킷을 다시 전송할 수 있게 됩니다.
결론!
rdt2.2는 NAK을 없애버렸어. 그래서 수신된 것에 오류 있으면, 이전 것을 ACK로 보내버려~
rdt3.0 성능 문제
1. stop and wait 방식 : 하나 실행 -> 완료까지 아무것도 못하고 대기해야해..
그러니까.. pipeline 사용해!
- pipelining 방식의 중요성
- 파이프라이닝 방식의 TCP에서는 여러 패킷을 동시에 전송할 수 있기 때문에 순서 번호의 범위가 커야 하고, 송신 측과 수신 측 모두 버퍼링이 필요합니다.
- 위의 조건 충족하는 방식
Go-Back-N (GBN): 손실된 패킷 이후의 모든 패킷을 재전송하는 방식입니다.
Selective Repeat (SR): 손실된 패킷만 선택적으로 재전송하는 방식입니다.
윈도우 크기(Window Size)는 네트워크 통신에서 송신 측이 확인 응답(ACK)을 기다리지 않고 연속적으로 전송할 수 있는 최대 패킷 수를 의미합니다. 이는 파이프라이닝 방식의 핵심 개념으로, 송신 측이 여러 패킷을 동시에 전송할 수 있게 하여 대기 시간을 줄이고 네트워크 효율성을 높이는 역할을 합니다.
패킷의 순서 번호
실제로 패킷의 순서 번호는 패킷 헤더 안의 고정된 길이 필드에 포함된다.
만약 k가 패킷 순서 번호 필드의 비트 수라면, 순서 번호의 범위는 [0, 2^k - 1]
순서 번호의 제한된 범위에서, 순서 번호를 포함하는 모든 계산은 모듈로(modulo) 2^k 연산을 이용한다.
순서 번호 필드와 비트 수 𝑘 패킷 순서 번호 필드는 패킷 헤더 내에 위치한 고정된 길이의 필드로, 패킷마다 고유한 순서 번호를 저장합니다. 이 필드의 비트 수를 𝑘라고 하면, 순서 번호로 표현할 수 있는 범위는 2 𝑘 2 k 개의 값입니다. 순서 번호의 범위는 [ 0 , 2 𝑘 − 1 ] 이 됩니다. 예를 들어: 𝑘 = 3 일 경우, 순서 번호의 범위는 2^3 = 8 이므로 0부터 7까지의 값이 됩니다. 𝑘 = 4 라면 순서 번호 범위는 0부터 15까지입니다. 순서 번호의 순환 (모듈로 2 𝑘 연산) 순서 번호의 범위는 고정된 범위를 가지므로, 전송할 패킷이 많아지면 순서 번호는 다시 처음으로 돌아와 순환해야 합니다. 예를 들어, 𝑘 = 3이라면 순서 번호는 0에서 7까지만 사용할 수 있습니다. 패킷을 8개 이상 전송해야 할 때, 순서 번호는 7 이후 다시 0으로 돌아가게 됩니다. 이러한 순환을 모듈로 2^k 연산을 통해 구현합니다. 예를 들어, 𝑘 = 3 일 때 패킷 8의 순서 번호는 8mod8=0이 되어 0번으로 다시 시작합니다. 패킷 9의 순서 번호는 9 m o d 8 = 1 이 되어 1번이 됩니다.
GBN 프로토콜은 슬라이딩 윈도 프로토콜(sliding-window protocol)
-> N개 위도우 저부 실행되면, 오른쪽으로 이동해서..
GBN역할
Selective Repeat (SR) : 손실되었다고 의심되는 것만 다시 요청
: window 처리 가능 내용 적어야하는 거 => 이게 SR!
time out은 loss 발생 후, 3번 이후 발생!
최소한의 윈도 크기는 얼마인가?
윈도 크기는 SR 프로토콜에 대한 순서 번호 공간 크기의 절반보다 작거나 같아야 한다
4 way handshaking
TCP 연결 종료의 4-way Handshake 과정
Client가 FIN 패킷 전송:
클라이언트는 연결을 종료하기 위해 서버로 FIN 패킷을 전송합니다.
이 요청은 "더 이상 데이터를 보내지 않겠다"는 의미입니다.
Server가 ACK 패킷 전송:
서버는 FIN 패킷을 수신하고, 클라이언트의 요청을 확인했다는 의미로 ACK 패킷을 클라이언트에 전송합니다.
이 상태에서 서버는 여전히 데이터를 클라이언트에 보낼 수 있으며, 클라이언트로부터 데이터를 받을 수는 없습니다.
Server가 FIN 패킷 전송:
서버도 데이터를 모두 전송하고 연결을 종료하려고 할 때, 클라이언트로 FIN 패킷을 전송합니다.
이는 "나도 더 이상 데이터를 보내지 않겠다"는 의미입니다.
Client가 ACK 패킷 전송:
클라이언트는 서버의 FIN 패킷을 받고, 확인 응답으로 ACK 패킷을 서버에 전송합니다.
이로써 연결이 완전히 종료되며, 클라이언트와 서버는 각자의 자원을 해제할 수 있습니다.
2 way handshaking
client -> server :: syn
server -> client :: ack
matter) 진짜 연결이 되었는지 확인 불가
(server -> client 가는 게 손상되면, 문제 :: half-open)
(timeout 떠서, 새로 보낸 게 문제됨 :: dup)
TCP round trip time, timeout
EstimatedRTT = (1- alpha)EstimatedRTT + alphaSampleRTT
현재 구할 값 = (1 - alpha)이전추정값 + alpha이번sample값
DevRTT는 RTT 변화율을 의미한다.
이는 SampleRTT가 EstimatedRTT로부터 얼마나 많이 벗어나는지에 대한 측으로 정의한다.
TCP RTT 분산(variance) 추정
분산RTT = (1- β) x 분산RTT + β x | 측정RTT – 추정RTT |
β = 0.25
DevRTT = (1 - β) × DevRTT + β × | SampleRTT - EstimatedRTT |
// 1-beta 이전값 + beta | 현재샘플-예측(얼마나 차이 있나) |
(권장되는 β의 값 : 0.25)
공식은 그냥 외우면 되는데.. 일단 fast transmit이 3개, 4개째에서 터지니까.. 4*devrtt + 추청인 듯
flow control
rwnd : 남은 용량
문제점과 해결법
호스트 B의 수신 버퍼는 rwnd = 0으로서 가득 찼고
호스트 A에게 rwnd = 0이라고 알린 후 호스트 B는 호스트 A에게 전송할 것이 없는 경우
호스트 B에서의 애플리케이션 프로세스가 버퍼를 비우더라도,
TCP는 호스트 A에게 새로운 rwnd로 새로운 세그먼트를 전송하지 않는다.
즉, TCP는 전송할 데이터가 있거나, 전송해야 할 확인응답을 가진 경우에만 호스트 A에게 세그먼트를 전송할 것이다.
→ 호스트 A는 차단되고 더는 데이터를 전송할 수 없다.
따라서 TCP 명세서는 호스트 A가 호스트 B의 수신 윈도가 0일 때, 1바이트 데이터로 세그먼트를 계속해서 전송하도록 요구한다.
수신 윈도우가 0일 때는 일반적인 데이터 전송은 차단되지만, TCP는 1바이트 probe 세그먼트를 예외적으로 처리할 수 있도록 설계되어 있습니다. 즉, 수신 윈도우가 0이라도 1바이트 probe 세그먼트는 수신 측에서 받아들여지며, 이로 인해 수신 측이 ACK를 보낼 수 있는 기회를 얻습니다.
1바이트 probe는 일반적인 데이터 전송이 아닌 TCP 연결 유지 및 상태 확인을 위한 특별한 메커니즘으로 간주되기 때문에, 수신 윈도우가 0이더라도 예외적으로 받아들여지고 응답됩니다. 이를 통해 송신 측은 수신 측의 현재 수신 윈도우 상태를 주기적으로 확인할 수 있고, 수신 버퍼에 공간이 생기면 ACK에 업데이트된 수신 윈도우 크기를 포함해 송신 측에 알립니다.
따라서, 수신 윈도우가 0인 상태에서도 1바이트 probe 세그먼트를 통해 수신 윈도우가 열렸는지 확인하고 데이터를 전송할 준비를 할 수 있습니다.
