10 주차 . 전송층 프로토콜 – UDP 와 TCP

1. 컴퓨터 네트워크 10주차. 전송층 프로토콜 – UDP와 TCP 2013년도 2학기 10주차

2. 10.1 전송층의 개요 • 전송 층은 프로세스간 전달을 책임진다. • 참고) 데이터 링크층은 노드간 전달을 책임진다. • 프로세스간 통신 방식  클라이언트-서버(client-server) 방식 • (로컬 호스트, 로컬 프로세스)  (원격지 호스트, 원격지 프로세스)

3. 10.1.1 포트 번호 • MAC 주소 – 다음 홉 장치에 대한 주소 (데이터링크층) • IP 주소 – 최종 목적지에 대한 주소 (네트워크층) • 포트 번호 (port number) • 호스트에서 동작중인 여러 개의 네트워킹 프로세스를 구별하기 위한 번호 • 인터넷에서의 포트번호 – 16비트로 0 ~ 65535 사이의 값 • 클라이언트 프로세스는 임시 포트번호를 할당 받아 사용. • 서버프로세스는 사전에 약속된 잘 알려진 포트번호를 사용

4. 포트번호의 종류 • IANA (Ineternet Assigned Number Authority) – 인터넷번호할당관리기관이 포트번호 관리 • 잘 알려진(well-known) 포트 • 0 ~ 1023 사이의 번호, IANA에 의해 통제 • 등록(registered) 포트 • 1024 ~ 49151 사이의 번호, IANA에 의해 통제 받지 않으나 중복방지를 위해 등록만 되어 있다. • 동적(dynamic) 포트 • 49152 ~ 65535 사이의 번호, IANA에 의해 통제 및 등록도 되어있지 않아서 어떠한 프로세스도 사용가능

5. 소켓 주소 • 소켓주소(socket address) – IP 주소와 포트번호의 조합 • 한쌍의 클라이언트 소켓 주소와 서버소켓 주소가 IP 헤더와 전송층(TCP 또는 UDP) 헤더에 포함

6. 10.1.2 비연결 대 연결 지향 서비스 (1) • 비연결 서비스 (connectionless service) • 연결설정이나 해제 없이 전송, 패킷에 번호가 부여되지 않으며 독립적으로 라우팅 되므로 순서가 뒤바뀔 수 있으며 확인응답도 없다  UDP • 연결지향 서비스 (connection-oriented service) • 연결설정후 데이터 전송, 종료시에는 연결 해제  TCP • 연결 설정 connection request에는 트래픽에 관한 초기화정보 (예로, 순서번호 등)가 포함 되어 있음

7. 비연결 대 연결 지향 서비스 (2) • 연결해제 • IP와 같은 비연결형 네트워크 층 위에 어떻게 연결지향 프로토콜을 만들 수 있는가? • 실제 패킷전달은 비연결형이지만 전송층이 순서를 맞추어 연결형으로 만듬 양측이 동시에 종료되기를 원치 않을 수도 있기때문에 세단계로 줄일수 없다.

8. 10.1.3 신뢰성대 비신뢰성 • 응용층이 신뢰성이 필요하면 서비스가 느리고 좀 더 복잡하지만 신뢰성 있는 전송층 프로토콜(TCP) 사용 • 응용 프로그램이 빠른 서비스 및 서비스 특성상 흐름제어나 오류제어가 필요없으면(실시간 응용) 비신뢰성 프로토콜(UDP) 사용 • 데이터링크층이 신뢰성을 제공하는 데 전송층이 또 신뢰성을 제공할 필요가 있는가?  데이터링크층이 네트워크층의 신뢰성을 다루지 못하기 때문에 필요

9. 10.2 사용자 데이터그램 프로토콜 (UDP) • 사용자데이터그램 프로토콜 (User Datagram Protocol, UDP) • 흐름 및 오류제어가 없는 비연결이고 신뢰성 없는 전송 프로토콜 • 최소한의 오버헤드를 가진 매우 간단한 프로토콜 • 작은 메시지를 송신하기를 원하고 신뢰성에 관하여 신경쓰지 않는 응용에 적합, 간단한 요청-응답 통신을 요구하는 프로세스에 적합 • 멀티미디어와 멀티캐스팅 응용에 적합

10. 잘 알려진 UDP 포트번호

11. UDP 패킷 형식 발신지 포트번호 수신지 포트번호 총길이 검사합

12. 10.3 TCP • 전송제어프로토콜(Transmission Control Protocol, TCP) • 스트림 연결지향(stream connection-oriented)의 신뢰성 있는 전송 프로토콜, UDP에 비해서 복잡 • 잘 알려진 TCP 포트번호

13. TCP 서비스 (1) • 스트림 전송 서비스 (Stream Delivery Service) • UDP: 한 뭉치의 바이트들을 송신, 뭉치 간 상관관계 없음 • TCP: 바이트의 흐름으로 데이터를 송수신

14. TCP 서비스 (2) • 송신 및 수신 버퍼(sending and receiving buffers)

15. TCP 서비스 (3) • 바이트와 세그먼트(segment) • 전이중 서비스 • 연결 지향 서비스 • 신뢰성 있는 서비스

16. 순서번호와 확인응답번호 • 순서번호와 확인응답번호를 사용하여 흐름제어와 오류제어를 수행 • 바이트 번호 • 전송되는 모든 데이터 바이트에 번호를 부여 • 번호의 범위: 0 ~ 232-1 • 전송을 시작하는 데이터의 번호는 임의로 선정 (0부터 할 필요 없음) • 예) 임의의 번호가 1057이고 6000바이트를 전송한다면, 1057에서 7056까지 번호가 매겨짐 • 순서번호 • 해당 세그먼트에서 운반하는 첫번째 바이트 번호 • 확인응답번호 • 수신을 기대하는 다음 바이트 번호 • 순서번호와 확인응답번호를 사용하여 흐름제어와 오류제어를 수행 • 예제 6.1) TCP로 6000바이트 전송, 첫번째 바이트의 번호는 10010, 1000바이트 크기의 4개의 세그먼트를 전송하고 2000바이트 크기의 세그먼트 1개를 전송할 때 각 세그먼트의 순서번호는? • 세그먼트1: 10010, 세그먼트2: 10010+1000 = 11010 • 세그먼트3: 11010+1000 = 12010, 세그먼트4: 10010+1000 = 13010 • 세그먼트5: 13010+1000 = 14010

17. 10.3.2 세그먼트 (Segment) 형식 • TCP를 사용하는 두 장치 사이의 데이터 전송 단위 • TCP 세그먼트 형식 (TCP segment format) 20~60바이트

18. TCP 세그먼트 • Source port address –발신지 포트 주소 • Destination port address –목적지 포트 주소 • Sequence number –순서번호, 이 세그먼트로 전송되는 첫 번째 데이터의 바이트 번호 • Acknowledgement number –확인응답번호, 받기를 기대하는 다음 데이터의 바이트 번호 • Header length –헤더 길이 • Reserved –예비, 사용 안 함 • Control –제어용 6비트: urg, ack, psh, rst, syn, fin 비트 • Window size –상대방 쪽이 유지해야 하는 바이트 단위의 윈도우의 크기, 수신자 윈도우(receiver window)의 크기 • Checksum –검사합 • Urgent pointer –긴급 지시자 • Options and padding –선택항목과 패딩 바이트

19. 제어용 6비트 (control field)

20. 10.3.3 TCP 연결 • 연결설정  데이터 송수신  연결 종료 • 연결설정 (Three-step connection establishment) + 삼방향 핸드쉐이크(Three-way handshake)

21. TCP 연결 • 연결 종료 (Four-step connection termination) • 연결 재설정 – RST 비트를 설정한 세그먼트를 보낼 때

22. TCP 상태 (States of TCP)

23. TCP 상태 천이도 (State Transition Diagram) • 실선: 클라이언트, 점선: 서버 • 입력/출력 FIN/ACK CLOSING 동시종료 FIN+ACK/ACK ACK/-

24. 10.3.4 TCP 흐름제어 • 목적지가 데이터로 넘쳐나지 않도록 하기 위하여 데이터의 흐름을 제어할 뿐만 아니라 전송을 좀더 효과적으로 만들기 위하여 사용 • TCP의 슬라이딩 윈도우는 바이트단위로 제어 • 송신자 버퍼 (sender buffer)

25. TCP 흐름제어 • 수신자 윈도우 (receiver window) • 수신측이 더 수신할 수 있는 크기 • 송신자 윈도우 (sender window) • 송신자 윈도우는 통보받은 수신자 윈도우의 크기와 동일하게 유지 버퍼 크기 = 13 채워져 있는 바이트수 = 6 receiver window = 7 Sender window = receiver window = 7, 3바이트를 보내고 확인응답 안되었다면 4바이트를 더 보낼 수 있다.

26. TCP 흐름제어 • 송신자 윈도우의 이동 (sliding sender window) 송신자가 2바이트를 더 보내고, receiver window =7과 확인응답(바이트 203)을 받았을 때

27. TCP 흐름제어 • 송신자 윈도우 확장 (expanding sender window) • 수신프로세스가 수신하는 속도(speed)보다 더 빠르게 처리할 때 수신자 윈도우가 커지므로 • 송신자 윈도우 축소 (shrinking sender window) • 수신프로세스가 수신하는 속도(speed)보다 더 천천히 처리하면 수신자 윈도우가 작아지므로 • 송신자 윈도우 종료 –수신자가 윈도우 크기 0을 통지할 때 더이상 전송이 불가능하고 0이 아닌 수신자 윈도우 크기가 통지될 때까지 기다림 송신자가 5바이트를 더 보내고, receiver window =10과 확인응답(바이트 205)을 받았을 때 송신자가 2바이트를 더 보내고, receiver window = 6과 확인응답(바이트 210)을 받았을 때

28. 4.3.5 어리석은 윈도우 신드롬(Silly Window Syndrom) • 송신프로세스가 데이터를 천천히 만들거나 수신프로세스가 늦게 처리하면 매우 작은 세그먼트로 데이터를 송신하는 결과가 초래되어 전송효율이 크게 감소한다. • 예) 1바이트만을 전송하는데도 40바이트의 오버헤드(TCP헤더+IP헤더)가 필요 • 송신 프로세스에 의해서 생성된 신드롬 • 송신프로세스가 매우 천천히 1바이트씩 만들어 내면 송신 TCP 1바이트의 데이터를 보내기 위해 41바이트의 세그먼트를 전송한다. • 대책: 송신 TCP는 데이터가 모일 때까지 기다린다.  얼마 동안? • Nagle의 알고리즘 • 송신 TCP는 단지 1바이트 일지라도 송신응용프로그램에서 수신한 첫 데이터 부분을 송신한다. • 첫번째 세그먼트를 송신한 후 확인응답이 수신될 때까지 또는 최대 크기의 세그먼트를 채울 정도로 데이터가 누적될 때까지 출력버퍼에 데이터를 모은다. • 나머지 전송에서는 단계 2를 반복한다.

29. 어리석은 윈도우 신드롬(Silly Window Syndrom) • 수신프로세스에 의해 생성된 신드롬 • 수신 프로세스가 수신 TCP로부터 매우 천천히 데이터를 가져가면 발생한다. 예를 들어 수신 TCP 입력버퍼가 4kbyte이고 꽉 차있다고 하자. 수신 TCP는 수신자윈도우 크기 0을 통보하고 송신 TCP는 송신을 중단한다. 수신 프로세스가 1바이트를 입력버퍼로부터 1바이트를 가져가면 수신 TCP는 수신자윈도우크기 1을 송신 TCP에게 통보하고 송신 TCP는 1바이트 데이터, 즉 41바이트의 세그먼트를 전송할 것이다. • Clark 해결방법 • 데이터 도착 즉시 확인응답을 보내나 최대 크기의 세그먼트를 받을 수 있는 공간이 있거나 버퍼의 절반이 비어있지 않으면 수신자 윈도우 크기 0을 통보 • 지연된 확인응답 • 입력 버퍼에 충분한 공간이 있을 때까지 확인응답전송을 지연한다. • 장점: 트래픽 감소 유발 • 단점: 너무 지연되면 송신 TCP가 재전송에 들어감  확인응답이 500ms이상 지연되서는 안됨

30. 10.3.6 TCP 오류 제어 (1) • 유실(lost) 또는 손상 세그먼트

31. 오류 제어 (2) • 중복 세그먼트 • 동일한 순서번호의 또 다른 세그먼트가 수신되면 폐기 • 순서 없는 세그먼트(out-of-order segment) • 순서가 어긋나게 도착한 세그먼트보다 앞에 있어야 하는 세그먼트가 모두 도착할 때까지 확인응답을 하지 않는다. • 유실된 확인응답 (lost acknowledgement)

32. 10.3.7 TCP 타이머와 기타 특징들 • 4개의 타이머를 사용함 • 재전송 타이머(retransmission timer) • 세그먼트의 확인응답을 기다리는 시간 • 재전송 시간 계산 –수신지 별로 물리적 거리도 다르므로 TCP 연결마다 다른 재전송 시간을 책정해야 하며, 또한 중간 혼잡에 의해서 전송되는 시간도 달라질 수 있으므로 동일 연결 동안에도 변할 수 있어야 한다. • 가장 흔한 방법 : 왕복시간(round-trip time, RTT)의 2배로 선정하는 것이다. 즉, 재전송시간 = 2 x RTT

33. TCP 타이머들 • RTT 계산 • 첫번째 방법: TCP 타임스탬프(timestamp) 선택 필드(option field)에서 제공되는 값 이용 • 두번째 방법: TCP 세그먼트(segment) 하나를 전송하고 확인응답(ACK)을 기다린 후 시간 계산 • 갱신: RTT = a * (이전 RTT) + (1 –a) * (현재 RTT), a는 보통 90% • 예) 이전 RTT = 250us, 현재 RTT = 70us RTT = (0.9 * 250) + (0.1 * 70) = 232us 재전송 시간 = 2 * 232us = 464us • Karn 알고리즘: 확인응답이 안되어서 재전송 할 경우, 수신된 확인응답은 원래 보낸 세그먼트에 대한 확인응답인지, 재전송한 세그먼트에 대한 확인응답인지 구별할 수 없기 때문에, 이러한 경우 RTT를 갱신하지 않는다. • 시간대기타이머(time-waited timer) • 완전 종료하기 전에 목적지에 도착한 중복 패킷들이 있으면 모두 폐기 처분되도록 세그먼트의 예상된 수명의 2배 시간 동안 기다림

34. TCP 타이머들 • 영속 타이머 (Persistence Timer) • 수신 TCP가 0값의 윈도우 크기를 통지한 후 얼마 뒤에 0이 아닌 값의 윈도우크기를 통지하는 확인응답을 보냈는데 이 확인응답이 유실되면 송수신 TCP 모두 기다리는 사태 발생 • 이러한 교착 상태를 해결하기 위해 송신 TCP는 0 크기의 윈도우가 통보되면 영속타이머를 가동, 영속타이머가 time-out 되면 프로브(probe) 세그먼트를 송신하여 확인응답을 재송신하라고 알림 • 영속타이머의 초기값은 재전송시간값으로 설정, 프로브에 대한 응답이 없을 시에는 타이머 값을 계속 2배로 늘려나가되, 60초가 넘어가면 60초마다 하나의 프로브 세그먼트를 송신 • 연결유지 타이머(keep-alive timer) • 클라이언트가 서버에게 연결을 요청한 후 갑자기 종료되면 TCP 연결이 영구히 개방된 채로 남음 • 연결마다 2시간 크기의 연결유지 타이머를 가동하되, 연락이 올 때마다 시간을 초기화 • 연결유지 타이머가 종료되면 75초 간격을 10번의 프로브를 보내고 그래도 응답이 없으면 종료됨

35. TCP의 두 가지 나머지 특징들 • 데이터 밀어 넣기 (Pushing Data) • 송신 프로세스가 송신 TCP에게 윈도우가 채워지는 것을 기다리지 말고 즉시 보내기를 요청할 때 PSH 비트를 설정 • 수신 TCP 또한 데이터가 더 들어오기를 기다리지 말고 바로 수신 프로세스에게 보내기를 요청 • 예) 대화형 통신을 하는 응용 프로그램 • 긴급 데이터 (Urgent Data) • 송신 프로세스가 이미 보낸 데이터에 앞서 먼저 처리되기를 원하는 데이터를 보낼 때 URG 비트를 설정 • 예) ctrl+c와 같은 중단명령을 보낼 때 • 긴급데이터는 세그먼트의 시작부분에 기록되고 긴급지시자 필드(urgent pointer filed)에는 긴급데이터의 종료지점이 기록됨

36. 10.3.8 TCP 혼잡 제어 (Congestion Control) • 라우터(router)의 패킷 처리 과정 • 도착된 패킷은 라우팅 순서를 기다리기 위해 입력 큐의 맨 뒤에 넣어짐 • 입력 큐(input queue)의 맨 앞에 오면 라우터 처리 모듈이 라우팅 테이블을 참고하여 출력 큐(output queue)를 결정 • 출력 큐의 맨 뒤에 넣어져 전송되기까지 기다림 • 혼잡(Congestion)이 발생하는 이유 • 패킷 도착률(arrival rate)이 패킷 처리율(processing rate)보다 높거나 패킷 출발률(departure rate)이 패킷 처리율보다 작으면 혼잡이 발생하고 큐에 저장될 수 없는 패킷은 폐기(discard)된다.

37. TCP의 혼잡 제어 (TCP Congestion Control) • 세그먼트가 유실(loss)되면 TCP는 재전송을 하게 되는데 만약 유실된 원인이 혼잡이면 세그먼트 재전송은 오히려 혼잡을 가중시킬 수 있다. • TCP는 유실된 세그먼트의 원인이 네트워크 내 혼잡이라고 가정한다. • 혼잡 윈도우 (congestion window) 도입 • TCP에서 송신자의 윈도우 크기는 통보받은 수신자 윈도우 크기 뿐만 아니라 네트워크의 혼잡에 의해 결정됨 • 실제 윈도우 크기 = 최소치 (수신자윈도우 크기, 혼잡윈도우 크기) • 혼잡 회피 (Congestion Avoidance) 방안 • 슬로우 스타트와 덧셈 증가 (slow start and additive increase) • 곱셈 감소 (multiplicative decrease)

38. TCP의 혼잡 제어의 예 slow start additive increase slow start additive increase 연결시작시 혼잡윈도우= 하나의 최대 세그먼트 크기 확인응답되면 임계치전까지는 윈도우의 크기를 지수적으로 (2배씩) 늘린다. 손실이 발생하면 임계치를 혼잡윈도우의 절반으로 줄이고 다시 처음부터 시작 임계치가 넘어가면 윈도우의 크기를 한 세그먼트씩 늘린다

39. 10.4 SCTP • 스트림 제어 전송 프로토콜 • Stream Control Transmission Protocol • IETF가 2000년에 추가한 새로운 전송 프로토콜 • TCP와 UDP의 장점을 조합 • UDP처럼 메시지 지향이면서 TCP처럼 신뢰성을 제공 • SCTP 응용과 포트번호

40. SCTP 특징 – 다중 스트림 지원

41. SCTP 특징 – 멀티 호밍

42. SCTP 특징 – 연결지향 및 신뢰성제공 • TCP처럼 연결지향 프로토콜임 • SCTP에서의 연결은연합(association)이라 함 • 신뢰성 제공을 위해 확인응답절차 사용

43. SCTP 헤더 형식 • 데이터 전송단위 – 가변길이의 청크 (chunk) • 청크는 메시지 또는 메시지 단편일 수 있음

44. SCTP 일반 헤더 형식 • 검증태크(verification tag) • SCTP 연합을 구별하기 위한 식별자

45. TCP 세그먼트와 SCTP 형식 비교

46. TSN, SI, SSN • TSN (Transmission Sequence Number) • 전송순서번호, 데이터청크들의 순서 • SI (Stream Identifier) • 스트림 식별자 • SSN (Stream Sequence Number) • 스트림 순서별로, 각 스트림 별 데이터청크들의 순서번호

47. SCTP 제어 청크의 종류

48. SCTP 연합 생성 절차

49. SCTP의데이터 전송 절차

50. SCTP 연합 종료 절차