Transcript 강의 PPT
컴퓨터 네트워크 10주차. 전송층 프로토콜 – UDP와 TCP 2013년도 2학기 10주차 10.1 전송층의 개요 전송 층은 프로세스간 전달을 책임진다. 참고) 데이터 링크층은 노드간 전달을 책임진다. 프로세스간 통신 방식 클라이언트-서버(client-server) 방식 (로컬 호스트, 로컬 프로세스) (원격지 호스트, 원격지 프로세스) Dept. of Information & Communications 2 10.1.1 포트 번호 MAC 주소 – 다음 홉 장치에 대한 주소 (데이터링크층) IP 주소 – 최종 목적지에 대한 주소 (네트워크층) 포트 번호 (port number) 호스트에서 동작중인 여러 개의 네트워킹 프로세스를 구별하기 위한 번호 인터넷에서의 포트번호 – 16비트로 0 ~ 65535 사이의 값 클라이언트 프로세스는 임시 포트번호를 할당 받아 사용. 서버프로세스는 사전에 약속된 잘 알려진 포트번호를 사용 Dept. of Information & Communications 3 포트번호의 종류 IANA (Ineternet Assigned Number Authority) – 인터넷번호 할당관리기관이 포트번호 관리 잘 알려진(well-known) 포트 0 ~ 1023 사이의 번호, IANA에 의해 통제 등록(registered) 포트 1024 ~ 49151 사이의 번호, IANA에 의해 통제 받지 않으나 중복방지 를 위해 등록만 되어 있다. 동적(dynamic) 포트 49152 ~ 65535 사이의 번호, IANA에 의해 통제 및 등록도 되어있지 않아서 어떠한 프로세스도 사용가능 Dept. of Information & Communications 4 소켓 주소 소켓주소(socket address) – IP 주소와 포트번호의 조합 한쌍의 클라이언트 소켓 주소와 서버소켓 주소가 IP 헤더와 전송층(TCP 또는 UDP) 헤더에 포함 Dept. of Information & Communications 5 10.1.2 비연결 대 연결 지향 서비스 (1) 비연결 서비스 (connectionless service) 연결설정이나 해제 없이 전송, 패킷에 번호가 부여되지 않으며 독립 적으로 라우팅 되므로 순서가 뒤바뀔 수 있으며 확인응답도 없다 UDP 연결지향 서비스 (connection-oriented service) 연결설정후 데이터 전송, 종료시에는 연결 해제 TCP 연결 설정 connection request에는 트래픽에 관한 초기화정보 (예로, 순서번호 등)가 포함 되어 있음 Dept. of Information & Communications 6 비연결 대 연결 지향 서비스 (2) 연결해제 양측이 동시에 종료되기를 원치 않을 수도 있기때문에 세단계로 줄일수 없다. IP와 같은 비연결형 네트워크 층 위에 어떻게 연결지향 프로 토콜을 만들 수 있는가? 실제 패킷전달은 비연결형이지만 전송층이 순서를 맞추어 연결형으 로 만듬 Dept. of Information & Communications 7 10.1.3 신뢰성 대 비신뢰성 응용층이 신뢰성이 필요하면 서비스가 느리고 좀 더 복잡하지만 신뢰성 있는 전송층 프로토콜(TCP) 사용 응용 프로그램이 빠른 서비스 및 서비스 특성상 흐름제어나 오류제어가 필요없으면(실시간 응용) 비신뢰성 프로토콜(UDP) 사용 데이터링크층이 신뢰성을 제공하는 데 전송층이 또 신뢰성을 제공할 필 요가 있는가? 데이터링크층이 네트워크층의 신뢰성을 다루지 못하기 때문에 필요 Dept. of Information & Communications 8 10.2 사용자 데이터그램 프로토콜 (UDP) 사용자데이터그램 프로토콜 (User Datagram Protocol, UDP) 흐름 및 오류제어가 없는 비연결이고 신뢰성 없는 전송 프로 토콜 최소한의 오버헤드를 가진 매우 간단한 프로토콜 작은 메시지를 송신하기를 원하고 신뢰성에 관하여 신경쓰 지 않는 응용에 적합, 간단한 요청-응답 통신을 요구하는 프 로세스에 적합 멀티미디어와 멀티캐스팅 응용에 적합 Dept. of Information & Communications 9 잘 알려진 UDP 포트번호 Port Protocol Description 7 Echo Echoes a received datagram back to the sender 9 Discard 11 Users 13 Daytime 17 Quote 19 Chargen 53 Nameserver 67 Bootps Server port to download bootstrap information 68 Bootpc Client port to download bootstrap information 69 TFTP Trivial File Transfer Protocol 111 RPC Remote Procedure Call 123 NTP Network Time Protocol 161 SNMP Simple Network Management Protocol 162 SNMP Simple Network Management Protocol (trap) Discards any datagram that is received Active users Returns the date and the time Returns a quote of the day Returns a string of characters Domain Name Service Dept. of Information & Communications 10 UDP 패킷 형식 발신지 포트번호 총길이 Dept. of Information & Communications 수신지 포트번호 검사합 11 10.3 TCP 전송제어프로토콜 (Transmission Control Protocol, TCP) 스트림 연결지향(stream connection-oriented)의 신뢰 성 있는 전송 프로토콜, UDP 에 비해서 복잡 잘 알려진 TCP 포트번호 Dept. of Information & Communications Port Protocol Description Echoes a received datagram back to the sender 7 Echo 9 Discard 11 Users 13 Daytime 17 Quote 19 Chargen 20 FTP, Data 21 FTP, Control 23 TELNET 25 SMTP 53 DNS 67 BOOTP 79 Finger Finger 80 HTTP Hypertext Transfer Protocol 111 RPC Discards any datagram that is received Active users Returns the date and the time Returns a quote of the day Returns a string of characters File Transfer Protocol (data connection) File Transfer Protocol (control connection) Terminal Network Simple Mail Transfer Protocol Domain Name Server Bootstrap Protocol Remote Procedure Call 12 TCP 서비스 (1) 스트림 전송 서비스 (Stream Delivery Service) UDP: 한 뭉치의 바이트들을 송신, 뭉치 간 상관관계 없음 TCP: 바이트의 흐름으로 데이터를 송수신 Dept. of Information & Communications 13 TCP 서비스 (2) 송신 및 수신 버퍼(sending and receiving buffers) Dept. of Information & Communications 14 TCP 서비스 (3) 바이트와 세그먼트(segment) 전이중 서비스 연결 지향 서비스 신뢰성 있는 서비스 Dept. of Information & Communications 15 순서번호와 확인응답번호 순서번호와 확인응답번호를 사용하여 흐름제어와 오류제어를 수행 바이트 번호 전송되는 모든 데이터 바이트에 번호를 부여 번호의 범위: 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 Dept. of Information & Communications 16 10.3.2 세그먼트 (Segment) 형식 TCP를 사용하는 두 장치 사이의 데이터 전송 단위 TCP 세그먼트 형식 (TCP segment format) 20~60바이트 Dept. of Information & Communications 17 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 – 선택항목과 패딩 바이트 Dept. of Information & Communications 18 제어용 6비트 (control field) Flag Description URG The value of the urgent pointer field is valid. ACK The value of the acknowledgment field is valid. PSH Push the data. RST The connection must be reset. SYN Synchronize sequence numbers during connection. FIN Terminate the connection. Dept. of Information & Communications 19 10.3.3 TCP 연결 연결설정 데이터 송수신 연결 종료 연결설정 (Three-step connection establishment) 삼방향 핸드쉐이크(Three-way handshake) Dept. of Information & Communications 20 TCP 연결 연결 종료 (Four-step connection termination) 연결 재설정 – RST 비트를 설정한 세그먼트를 보낼 때 Dept. of Information & Communications 21 TCP 상태 (States of TCP) State Description CLOSED There is no connection. LISTEN The server is waiting for calls from the client. SYN-SENT A connection request is sent; waiting for acknowledgment. SYN-RCVD A connection request is received. ESTABLISHED Connection is established. FIN-WAIT-1 The application has requested the closing of the connection. FIN-WAIT-2 The other side has accepted the closing of the connection. TIME-WAIT Waiting for retransmitted segments to die. CLOSE-WAIT The server is waiting for the application to close. LAST-ACK The server is waiting for the last acknowledgment. Dept. of Information & Communications 22 TCP 상태 천이도 (State Transition Diagram) • 실선: 클라이언트, 점선: 서버 • 입력/출력 FIN/ACK CLOSING 동시종료 FIN+ACK/ACK ACK/- Dept. of Information & Communications 23 10.3.4 TCP 흐름제어 목적지가 데이터로 넘쳐나지 않도록 하기 위하여 데이터의 흐름을 제어 할 뿐만 아니라 전송을 좀더 효과적으로 만들기 위하여 사용 TCP의 슬라이딩 윈도우는 바이트단위로 제어 송신자 버퍼 (sender buffer) Dept. of Information & Communications 24 TCP 흐름제어 수신자 윈도우 (receiver window) 수신측이 더 수신할 수 있는 크기 버퍼 크기 = 13 채워져 있는 바이트수 = 6 receiver window = 7 송신자 윈도우 (sender window) 송신자 윈도우는 통보받은 수신자 윈도우의 크기와 동일하게 유지 Sender window = receiver window = 7, 3바이트를 보내고 확인응답 안되었다면 4바이트를 더 보낼 수 있다. Dept. of Information & Communications 25 TCP 흐름제어 송신자 윈도우의 이동 (sliding sender window) 송신자가 2바이트를 더 보내고, receiver window =7과 확인응답(바이트 203)을 받았을 때 Dept. of Information & Communications 26 TCP 흐름제어 송신자 윈도우 확장 (expanding sender window) 수신프로세스가 수신하는 속도(speed)보다 더 빠르게 처리할 때 수신자 윈 도우가 커지므로 송신자가 5바이트를 더 보내고, receiver window =10과 확인응답(바이트 205)을 받았을 때 송신자 윈도우 축소 (shrinking sender window) 수신프로세스가 수신하는 속도(speed)보다 더 천천히 처리하면 수신자 윈도 우가 작아지므로 송신자가 2바이트를 더 보내고, receiver window = 6과 확인응답(바이트 210)을 받았을 때 송신자 윈도우 종료 – 수신자가 윈도우 크기 0을 통지할 때 더이상 전송 이 불가능하고 0이 아닌 수신자 윈도우 크기가 통지될 때까지 기다림 Dept. of Information & Communications 27 4.3.5 어리석은 윈도우 신드롬(Silly Window Syndrom) 송신프로세스가 데이터를 천천히 만들거나 수신프로세스가 늦게 처리하면 매우 작은 세그먼트로 데이터를 송신하는 결 과가 초래되어 전송효율이 크게 감소한다. 예) 1바이트만을 전송하는데도 40바이트의 오버헤드(TCP헤더+IP헤 더)가 필요 송신 프로세스에 의해서 생성된 신드롬 송신프로세스가 매우 천천히 1바이트씩 만들어 내면 송신 TCP 1바 이트의 데이터를 보내기 위해 41바이트의 세그먼트를 전송한다. 대책: 송신 TCP는 데이터가 모일 때까지 기다린다. 얼마 동안? Nagle의 알고리즘 송신 TCP는 단지 1바이트 일지라도 송신응용프로그램에서 수신한 첫 데이터 부분을 송신한다. 첫번째 세그먼트를 송신한 후 확인응답이 수신될 때까지 또는 최대 크기 의 세그먼트를 채울 정도로 데이터가 누적될 때까지 출력버퍼에 데이터 를 모은다. 나머지 전송에서는 단계 2를 반복한다. Dept. of Information & Communications 28 어리석은 윈도우 신드롬(Silly Window Syndrom) 수신프로세스에 의해 생성된 신드롬 수신 프로세스가 수신 TCP로부터 매우 천천히 데이터를 가져가면 발생한다. 예를 들어 수신 TCP 입력버퍼가 4kbyte이고 꽉 차있다고 하자. 수신 TCP는 수신자윈도우 크기 0을 통보하고 송신 TCP는 송 신을 중단한다. 수신 프로세스가 1바이트를 입력버퍼로부터 1바이트 를 가져가면 수신 TCP는 수신자윈도우크기 1을 송신 TCP에게 통보 하고 송신 TCP는 1바이트 데이터, 즉 41바이트의 세그먼트를 전송 할 것이다. Clark 해결방법 데이터 도착 즉시 확인응답을 보내나 최대 크기의 세그먼트를 받을 수 있는 공간이 있거나 버퍼의 절반이 비어있지 않으면 수신자 윈도우 크기 0을 통보 지연된 확인응답 입력 버퍼에 충분한 공간이 있을 때까지 확인응답전송을 지연한다. 장점: 트래픽 감소 유발 단점: 너무 지연되면 송신 TCP가 재전송에 들어감 확인응답이 500ms이상 지연되서는 안됨 Dept. of Information & Communications 29 10.3.6 TCP 오류 제어 (1) 유실(lost) 또는 손상 세그먼트 Dept. of Information & Communications 30 오류 제어 (2) 중복 세그먼트 동일한 순서번호의 또 다른 세그먼트가 수신되면 폐기 순서 없는 세그먼트(out-of-order segment) 순서가 어긋나게 도착한 세그먼트보다 앞에 있어야 하는 세그먼트가 모두 도착할 때까지 확인응답을 하지 않는다. 유실된 확인응답 (lost acknowledgement) Dept. of Information & Communications 31 10.3.7 TCP 타이머와 기타 특징들 4개의 타이머를 사용함 재전송 타이머(retransmission timer) 세그먼트의 확인응답을 기다리는 시간 재전송 시간 계산 – 수신지 별로 물리적 거리도 다르므로 TCP 연결마다 다 른 재전송 시간을 책정해야 하며, 또한 중간 혼잡에 의해서 전송되는 시간도 달라질 수 있으므로 동일 연결 동안에도 변할 수 있어야 한다. 가장 흔한 방법 : 왕복시간(round-trip time, RTT)의 2배로 선정하는 것이다. 즉, 재 전송시간 = 2 x RTT Dept. of Information & Communications 32 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배 시간 동안 기다림 Dept. of Information & Communications 33 TCP 타이머들 영속 타이머 (Persistence Timer) 수신 TCP가 0값의 윈도우 크기를 통지한 후 얼마 뒤에 0이 아닌 값 의 윈도우크기를 통지하는 확인응답을 보냈는데 이 확인응답이 유실 되면 송수신 TCP 모두 기다리는 사태 발생 이러한 교착 상태를 해결하기 위해 송신 TCP는 0 크기의 윈도우가 통보되면 영속타이머를 가동, 영속타이머가 time-out 되면 프로브 (probe) 세그먼트를 송신하여 확인응답을 재송신하라고 알림 영속타이머의 초기값은 재전송시간값으로 설정, 프로브에 대한 응답 이 없을 시에는 타이머 값을 계속 2배로 늘려나가되, 60초가 넘어가 면 60초마다 하나의 프로브 세그먼트를 송신 연결유지 타이머(keep-alive timer) 클라이언트가 서버에게 연결을 요청한 후 갑자기 종료되면 TCP 연 결이 영구히 개방된 채로 남음 연결마다 2시간 크기의 연결유지 타이머를 가동하되, 연락이 올 때마 다 시간을 초기화 연결유지 타이머가 종료되면 75초 간격을 10번의 프로브를 보내고 그래도 응답이 없으면 종료됨 Dept. of Information & Communications 34 TCP의 두 가지 나머지 특징들 데이터 밀어 넣기 (Pushing Data) 송신 프로세스가 송신 TCP에게 윈도우가 채워지는 것을 기다리지 말고 즉시 보내기를 요청할 때 PSH 비트를 설정 수신 TCP 또한 데이터가 더 들어오기를 기다리지 말고 바로 수신 프 로세스에게 보내기를 요청 예) 대화형 통신을 하는 응용 프로그램 긴급 데이터 (Urgent Data) 송신 프로세스가 이미 보낸 데이터에 앞서 먼저 처리되기를 원하는 데이터를 보낼 때 URG 비트를 설정 예) ctrl+c와 같은 중단명령을 보낼 때 긴급데이터는 세그먼트의 시작부분에 기록되고 긴급지시자 필드 (urgent pointer filed)에는 긴급데이터의 종료지점이 기록됨 Dept. of Information & Communications 35 10.3.8 TCP 혼잡 제어 (Congestion Control) 라우터(router)의 패킷 처리 과정 도착된 패킷은 라우팅 순서를 기다리기 위해 입력 큐의 맨 뒤에 넣어짐 입력 큐(input queue)의 맨 앞에 오면 라우터 처리 모듈이 라우팅 테이블을 참고하여 출력 큐(output queue)를 결정 출력 큐의 맨 뒤에 넣어져 전송되기까지 기다림 혼잡(Congestion)이 발생하는 이유 패킷 도착률(arrival rate)이 패킷 처리율(processing rate)보다 높거나 패킷 출발률(departure rate)이 패킷 처리율보다 작으면 혼잡이 발생하고 큐에 저 장될 수 없는 패킷은 폐기(discard)된다. Dept. of Information & Communications 36 TCP의 혼잡 제어 (TCP Congestion Control) 세그먼트가 유실(loss)되면 TCP는 재전송을 하게 되는데 만약 유실된 원 인이 혼잡이면 세그먼트 재전송은 오히려 혼잡을 가중시킬 수 있다. TCP는 유실된 세그먼트의 원인이 네트워크 내 혼잡이라고 가정한다. 혼잡 윈도우 (congestion window) 도입 TCP에서 송신자의 윈도우 크기는 통보받은 수신자 윈도우 크기 뿐만 아니 라 네트워크의 혼잡에 의해 결정됨 실제 윈도우 크기 = 최소치 (수신자윈도우 크기, 혼잡윈도우 크기) 혼잡 회피 (Congestion Avoidance) 방안 슬로우 스타트와 덧셈 증가 (slow start and additive increase) 곱셈 감소 (multiplicative decrease) Dept. of Information & Communications 37 TCP의 혼잡 제어의 예 slow start additive increase slow start 연결시작시 혼잡윈도우= 하나의 최대 세그먼트 크기 확인응답되면 임계치전까지는 윈도우의 크기를 지수적으로 (2배씩) 늘린다. 임계치가 넘어가면 윈도우의 크기를 한 세그먼트씩 늘린다 Dept. of Information & Communications additive increase 손실이 발생하면 임계치를 혼잡윈도우의 절반으로 줄이고 다시 처음부터 시작 38 10.4 SCTP 스트림 제어 전송 프로토콜 Stream Control Transmission Protocol IETF가 2000년에 추가한 새로운 전송 프로토콜 TCP와 UDP의 장점을 조합 UDP처럼 메시지 지향이면서 TCP처럼 신뢰성을 제공 SCTP 응용과 포트번호 Dept. of Information & Communications 39 SCTP 특징 – 다중 스트림 지원 Dept. of Information & Communications 40 SCTP 특징 – 멀티 호밍 Dept. of Information & Communications 41 SCTP 특징 – 연결지향 및 신뢰성제공 TCP처럼 연결지향 프로토콜임 SCTP에서의 연결은 연합(association)이라 함 신뢰성 제공을 위해 확인응답절차 사용 Dept. of Information & Communications 42 SCTP 헤더 형식 데이터 전송단위 – 가변길이의 청크 (chunk) 청크는 메시지 또는 메시지 단편일 수 있음 Dept. of Information & Communications 43 SCTP 일반 헤더 형식 검증태크(verification tag) SCTP 연합을 구별하기 위한 식별자 Dept. of Information & Communications 44 TCP 세그먼트와 SCTP 형식 비교 Dept. of Information & Communications 45 TSN, SI, SSN TSN (Transmission Sequence Number) 전송순서번호, 데이터청크들의 순서 SI (Stream Identifier) 스트림 식별자 SSN (Stream Sequence Number) 스트림 순서별로, 각 스트림 별 데이터청크들의 순서번호 Dept. of Information & Communications 46 SCTP 제어 청크의 종류 Dept. of Information & Communications 47 SCTP 연합 생성 절차 Dept. of Information & Communications 48 SCTP의 데이터 전송 절차 Dept. of Information & Communications 49 SCTP 연합 종료 절차 Dept. of Information & Communications 50 SCTP에서 수신측 흐름 제어 Dept. of Information & Communications 51 SCTP에서 송신측 흐름 제어 Dept. of Information & Communications 52 SCTP 흐름 제어 Dept. of Information & Communications 53