3.3 비연결형 트랜스포트: UDP 177
3.3.1 UDP 세그먼트 구조 181
3.3.2 UDP 체크섬 181
UDP 동작 방법에 대해 알아보쟈~
- 트랜스포트 프로토콜 설계
- 아무리 그래도 최소한의 동작은 수행해야함 ㅇㅇ
- 즉, 트랜스포트 계층은 네트워크 계층과 해당하는 애플리케이션 레벨 프로세스 간의 데이터를 넘겨주기 위해 적어도 다중화와 역다중화 서비스를 제공해야함
- UDP는 최소 기능으로 동작
- 다중화/역다중화 기능
- 간단한 오류 검사 기능
- 외 IP에 아무것도 안함ㅋㅋ
- 애플리케이션은 거의 IP와 직접 통신하는 셈
- UDP로 세그먼트 전달 : 애플리케이션 프로세스로부터 메시지를 가져옴 -> 다중화/역다중화 서비스에 대한 출발지 포트 번호 필드와 목적지 포트 번호 필드를 첨부 + 다른 두 필드 추가 -> 최종 세그먼트를 네트워크 계층으로 전달
- 네트워크 계층 : 트랜스포트 계층 세그먼트를 IP 데이터그램으로 캡슐화 -> 세그먼트를 수신 호스트에게 전달(최선형)
- 세그먼트가 수신 호스트에 도착 : UDP는 세그먼트의 데이터를 해당 애플리케이션 프로세스로 전달(목적지 포트 번호 사용)
- UDP는 세그먼트 송신하기 전, 송신 트렌스포트 계층 개체들과 수신 트랜스포트 계충 개체들 사이에 핸드셰이크X
- => 비연결형
- ex) DNS
- 신뢰있는 TCP 쓰지 UDP 왜씀ㅋㅋ? 이유 ㄱ
- 무슨 데이터를 언제 보낼지에 대해 애플리케이션 레벨에서 더 정교한 제어
- UDP는 데이터 받자마자 데이터를 UDP 세그먼트로 만들고，그 세그먼트를 즉시 네트워크 계충으로 전달
- TCP는 혼잡제어 -> 혼잡해지면 TCP 송신자 제한, 전달시간 관계없이 응답할 때까지 재전송 계속함 -> 실시간에서 에바 ㅋㅋ
- 연결 설정이 없음
- 세 방향 핸드셰이크(three-way handshake) 안함 -> 연결 설정에 지연이 없음 -> DNS에서 쓰기 좋음
- HTTP 문서로된 웹페이지는 신뢰성이 좋아야하니까 TCP 씀
- ㄴ 근데 연결 설정 지연은 웹 문서 다운로드 지연의 심각한 원임임ㅋㅋ
-> QUIC(Quick UDP Internet Connection) : UDP 위에 애플리케이션 계층 프로토콜 안정성 구현
ㄴ 구글 크롬 브라우저에서 사용
- 연결 상태가 없음
- 연결 상태 : 수신 버퍼, 송신 버퍼，혼잡 제어 파라미터，순서 번호, 확인응답 번호 파라미터 포함
- TCP와 달리 UDP는 연결 상태를 유지하지 않으며 이 파라미터 중 어떤 것도 기록하지 않음
- 일반적으로 특정 애플리케이션 전용 서버는 TCP보다 UDP에서 동작할 때 더 많은 액티브 클라이언트를 수용 가능
- 작은 패킷 헤더 오버헤드
- TCP : 20바이트의 헤더 오버헤드
- UDP : 8바이트의 오버헤드
- 무슨 데이터를 언제 보낼지에 대해 애플리케이션 레벨에서 더 정교한 제어
- 네트워크 관리 애플리케이션 = 혼잡상태 있을 때 자주 동작 : TCP > UDP
- DNS = 연결 설정 지연 회피해야함 : TCP < UDP
- 실시간,스트리밍, 멀티미디어 = 혼잡제어는 나쁜영향 : TCP < UDP
- 모든 애플리케이션에서는 적은 양의 패킷 손실 허용 ㅇㅇ -> 신뢰적 데이터 전송이 절대적으로 중요한 건 아님 ㅇㅇ
- UDP 써도 신뢰적인 데이터 전송 가능함!
- 애플리케이션이 신뢰성을 애플리케이션 자체에서 제공한다면! 가능! (확인응답 메커니즘, 재전송 메커니즘 추가 등）
- QUIC 프로토콜
👀 3.3.1 UDP 세그먼트 구조
- 애플리케이션 데이터는 UDP 데이터그램의 데이터 필드에 위치
- ex) DNS에 대한 데이터 필드 : 질의 메시지나 응답 메시지를 포함
- ex) 스트리밍 오디오 애플리케이션 데이터 필드 : 오디오 샘플
- UDP 헤더는 2바이트씩 구성된 단 4개의 필드만 가짐
- 출발지, 목적지 포트 번호 : 목적지 호스트가 역다중화 기능을 수행하는 정확한 프로세스에게 애플리케이션 데이터를 넘기도록 함.
- 체크섬（checksum）: 세그먼트에 오류가 발생했는지를 검사하기 위해 수신 호스트가 사용
- UDP 세그먼트 이외에 IP 헤더의 일부 필드도 계산하지만，전체 그림을 보기 위해 이러한 세부 사항은 무시
- 길이 필드 : 헤더를 포함하는 UDP 세그먼트의 길이（바이트 단위）를 나타냄
✅ 3.3.2 UDP 체크섬
- UDP 체크섬은 오류 검출을 위한 것
- : 세그먼트가 출발지로부터 목적지로 이동했을 때（예: 링크의 잡음에 의해 또는 라우터에서 저장되는 동안），UDP 세그먼트
안의 비트에 대한 변경사항이 있는지 검사 - 송신자 측에서 UDP는 세그먼트 안에 있는 모든 16비트 워드의 합산에 대해 다시 1의 보수를 수행
- 합산 과정에서 발생하는 오버플로는 윤회식 자리올림（wrap around）적용
- 이 결괏값을 UDP 세그면트의 체크성 필드에 삽입
- 만약 패킷에 어떤 오류도 없다면，수신자에서의 합은 11111111H111111
- 만약 비트 중에 하나라도 0이 있다면 패킷에 오류 발생했음을 알 수 있음.
- 왜 UDP가 체크섬을 제공함??
- 출발지와 목적지 사이의 모든 링크가 오류 검사를 제공한다는 보장이 없기 때문
- 종단과 종단의 원칙（end-end principle）: ㄴ 때메 UDP는 오류검사 꼭 해야함 ㅇㅇ
- IP는 어떠한 2계충 프로토콜에서도 동작해야 하므로，트랜스포트 계층은 안전장치로서 오류 검사를 제공하는 것이 유용
- UDP는 오류 검사를 제공하지만, 오류를 회복하기 위한 어떤 일도 하지 않음
- 손상된 세그먼트를 그냥 버리기
- 경고와 함께 손상된 세그먼트를 애플리케이션에게 넘겨주기
인생 살자.