1. 의사 헤더의 정보는 실제 정보인가? 1 / 23 UDP의 허용된 계층위반 UDP는 발신지와 수신지 IP 주소를 얻기 위해 IP Layer를 조회하여 가상헤더를 구성함. 프로토콜 구현상 IP 계층의 정보는 데이터가 UDP로 전해질 때 쉽게 접근 가능함. htons() short intger(일반적으로 2byte)데이터를 네트워크 byte order로 변경한다. 12장을 들어가기에 앞서 저번 시간에 보충하기로 한 내용에 대해 이야기 하겠습니다. UDP와 TCP의 체크섬을 계산할 때 의사헤더를 추가하는데 이 의사 헤더의 정보는 실제 정보인지에 대해 물으셨습니다. 의사헤더를 만들 때 프로토콜 구현상 계층위반을 저지르게 됩니다. Code에서와 같이 의사헤더에 들어가는 IP주소를 쉽게 접근할 수가 있습니다. < UDP 의사헤더의 요소를 모두 더하는 code > 1 / 23

2. 체크섬 계산(IP) 2 / 23 IP 체크섬 계산 [ Input ] [function] ip_header 먼저 왼쪽은 INPUT 값으로 들어갈 총 20bytes의 IP 헤더를 나타냈습니다. 오른쪽은 ip_checksum을 계산 할 함수 입니다. 계산 과정으로는 먼저 헤더를 2바이트씩 잘라 모두 더합니다. 캐리가 있을경우엔 캐리를 더해줍니다. 1의 보수 형태를 취해 반환해줍니다. 2 / 23

2. 체크섬 계산(UDP) 3 / 23 //홀수 길이라면 패드 바이트를 더함 //UDP 데이터그램을 2byte씩 잘라서 더함. //의사헤더의 src IP 부분을 더함. UDP 체크섬을 계산하는건 IP와 크게 다를게 없습니다. 차이점이라고 하면 의사헤더의 내용을 더해주는 것입니다. 주석참고. //의사헤더의 dst IP 부분을 더함. //의사헤더의 protocol 번호와 udp 길이를 더함. 의사헤더 계산 //16bit를 넘어가는 carry가 존재한다면 carry를 더함. //1의 보수를 취해줌. 3 / 23

3. UDP 데이터가 512바이트 이하로 제한된 이유 4 / 23 재조립을 위한 IPv4 버퍼 사이즈 최소 576bytes. 이를 위한 송신자 UDP 데이터 제한 512bytes 이하. 이유: RFC 791 576bytes – 60bytes (최대 IPv4 헤더 크기) – 8bytes(UDP 헤더 크기) = 508 byte. IP&UDP헤더를 뺀 사이즈(508bytes) < UDP 데이터 제한(512bytes)? => IPv4 header의 일반적인 크기는 20 byte이므로 순수 data의 크기가 좀 더 커도 상관 없음. 가끔 전송 실패 할 때가 있음. 교재에 따르면 재조립을 위한 IPv4 버퍼 사이즈는 576bytes 이하가 되야 한다고 합니다. 이 중 UDP 애플리케이션의 데이터를 512byte 이하로 제한하게 되어있습니다. 계산을 하게 되면 4bytes 만큼의 오차가 존재합니다. 그 이유를 RFC(Request for Comments)문서에서 찾으면 일반적인 인터넷 헤더는 20 octets이므로 상위 레벨 프로토콜을 조금 더 허용할 수 있다. 라고 설명 되어 있습니다. 2019년 4월 14일 오전 2시 34분 4 / 23

4. Setsockopt() api 코딩 예제 5 / 23 setsockopt() : 소켓의 옵션값을 설정하는 함수 Level : 소켓 옵션의 레벨 => Optname : 옵션의 이름 Optval : 옵션 정보를 저장한 버퍼의 포인터 Optlen : optval 버퍼의 크기 Setsockopt()는 소켓의 옵션값을 설정하는 함수로 함수원형은 이것과 같습니다. 다음 2019년 4월 14일 오전 2시 34분 5 / 23

4. Setsockopt() api 코딩 예제 6 / 23 API를 이용하여 buffer size 변경 이 그림은 Setsockopt를 사용한 Buffer size 변경 예제 입니다. 함수 호출 전 버퍼 사이즈는 87380이고 함수 호출 후 버퍼 사이즈는 100000로 변경 되었습니다. 2019년 4월 14일 오전 2시 34분 6 / 23

5. Man sock –u –s 7 / 23 - SOCK 책의 저자가 만든 프로그램 Sock 프로그램의 사용법입니다. 여기서 인자 U는 UDP를 사용한다는 것이고 인자 S는 Server를 만든다는 것입니다. 2019년 4월 14일 오전 2시 34분 7 / 23

6. UDP 종단점 생성 로컬 IP 주소의 제약 UDP 서버는 종단점을 생성할 때 자신의 로컬 IP 주소를 wildcard화 함. 들어오는 UDP 데이터 그램을 모두 받아 들이기 위함. 포트 7777로 들어오는 모든 외부 ip에 대해 허락 함. 로컬 IP주소를 wildcard화 한다는 것은 어떤 IP주소든 허락한다는 의미이며 그림에서 udp server 7777을 만들면 포트 7777로 들어오는 모든 외부 ip에 대해 허락한다는 의미 입니다. Local address 사용자 ip Foreign address 상대 ip -l 소켓 목록 -n ip주소 출력 --udp udp 출력 2019년 4월 14일 오전 2시 34분 8 / 20

7. 다중 주소 설정(가능 여부) Ip addr add 10.0.2.13 scope host dev eth0 Ip addr add 10.0.2.14 scope host dev eth0 sock –u –s –A 10.0.2.13 8888 ( -u: udp, -s: server, -A: SO_REUSEADDR) sock –u –s –A 10.0.2.14 8888 sock –u –s –a 8888 다중 주소 설정의 예시를 보이기 위해 Eth0 인터페이스에 13과 14 아이피를 관찰하도록 설정하고 Sock 프로그램으로 2019년 4월 14일 오전 2시 34분 9 / 23

So_reuseaddr 2019년 4월 14일 오전 2시 34분 10 / 23

12. TCP: 전송 제어 프로토콜 2015. 7. 11 김 진 홍 jhkim3624@etri.re.kr

contents 개요 TCP 소개 TCP 헤더와 캡슐화 정리

1. 개요 13 / 23 TCP 연결 지향의 신뢰성 있는 바이트 스트림을 제공 UDP와 같은 네트워크 계층을 이용 연결지향 TCP를 이용하는 2개의 애플리케이션이 데이터를 교환하기 전에 TCP 연결을 확립함을 의미 2019년 4월 14일 오전 2시 34분 13 / 23

1. 개요 - 계속 14 / 23 통신 문제 해결 방법 부호이론 전송을 반복해서 시도 정보를 전달할 때에 효율을 높이기 위해 또는 정보의 보호를 위하여 부호로 바꾸어 전달하는 것을 연구. 오류정정코드 일부 비트에 피해가 발생 하더라도 실제 정보를 추출할 수 있는 여분의 비트를 추가 전송을 반복해서 시도 ARQ(Automatic Repeat reQuest, 자동 반복 요구) 2019년 4월 14일 오전 2시 34분 14 / 23

1. 개요 - 계속 15 / 23 재전송 : 비트 오류를 다루기 위한 방법 중 하나 재전송을 위해 다음이 필요함 : 수신자가 패킷을 수신했는지 여부 수신한 패킷이 동일한지 여부 수신자는 패킷을 수신 했을 때 ACK를 전송 함 송신자가 ACK를 받으면 다음 패킷을 보냄 Question Q1. 송신자가 ACK를 얼만큼 기다릴 것인가? (14장) Q2. ACK가 분실된다면 무슨 일이 발생하는가?(다음) Q3. 패킷을 수신했으나 오류가 있을 경우?(다음) 2019년 4월 14일 오전 2시 34분 15 / 23

1. 개요 - 계속 16 / 23 Q2. ACK가 분실된다면 무슨 일이 발생하는가? 송신측은 패킷이 폐기된 경우와 구분하기 어려움. 송신기는 패킷을 재전송 함. Q3. 패킷을 수신했으나 오류가 있을 경우? 패킷의 오류검출을 위해 CRC를 사용함. 오류가 포함 되어 있다면 ACK 전송을 억제함. 송신기는 패킷을 재전송 하게 됨. 문제점 (1) 여러 가지 이유로 인해 패킷의 사본을 중복 수신할 가능성. (2) 송신자는 ACK 대기 시간동안 아무것도 하지 못함. 해결책 (1) 순서번호(sequence number)를 이용함. (2) 패킷의 윈도우와 슬라이딩 윈도우 2019년 4월 14일 오전 2시 34분 16 / 23

1. 개요 - 계속 17 / 23 슬라이딩 윈도우 현재 윈도우, 크기 = 3 … 3 4 5 6 7 전송과 확인응답 아직 전송되지 않은 것 윈도우 오른쪽 끝 윈도우 왼쪽 끝 … 3 4 5 6 7 2019년 4월 14일 오전 2시 34분 17 / 23

1. 개요 - 계속 18 / 23 송신측 어떤 패킷이 해제 됐는지 어떤 패킷이 ACK를 기다리는지 어떤 패킷이 아직 전송되지 않았는지 수신측 어떤 패킷이 수신되고 응답했는지 어떤 패킷이 기대되는지 어떤 패킷이 제한된 메모리로 인해 유지 되지 못하는지 문제점 얼마나 큰 윈도우를 사용해야 하는가? => 흐름제어로 해결 수신기와 네트워크가 송신기의 데이터 전송률을 처리하지 못한다면 어떤 일이 발생 하는가? =>흐름제어와 혼잡제어 2019년 4월 14일 오전 2시 34분 18 / 23

1. 개요 - 계속 19 / 23 흐름 제어 송신기의 속도를 강제로 늦추는 방법 (1) 전송률 기반 (2) 윈도우 기반 문제점 송신기에 전송률을 할당하고 그것을 초과해 전송하지 못하게 보장 함 (2) 윈도우 기반 슬라이딩 윈도우 사용시 많이 사용됨 윈도우 크기를 시간에 따라 변화하도록 함 윈도우 광고를 사용 함. 수신기가 송신기에게 얼마나 큰 윈도우를 사용할 수 있는지 전달하는 방법 문제점 송신기와 수신기 사이 네트워크에서는 효율적이지 못함 송신기의 전송률이 라우터의 능력을 초과할 가능성이 있음 혼잡 제어가 필요 2019년 4월 14일 오전 2시 34분 19 / 23

1. 개요 - 계속 20 / 23 혼잡 제어 송신기가 네트워크를 압도하지 못하게 천천히 하는 것 16장에서 다룸. 2019년 4월 14일 오전 2시 34분 20 / 23

2. TCP 소개 21 / 23 신뢰성 제공을 위해 순서번호 체크섬 각 패킷의 처음 바이트에 대한 오프셋 바이트 가변크기 허용과 재 패킷화에 사용 됨 순서번호를 사용하면 중복 세그먼트를 폐기하고 세그먼트의 순서를 조정할 수 있음. 체크섬 TCP 헤더와 데이터, IP 헤더로부터 체크섬을 계산함. 정확하지 않은 체크섬을 가지고 도착하면 그 패킷을 폐기하고 ACK를 보내지 않음. 2019년 4월 14일 오전 2시 34분 21 / 23

2. TCP 소개 22 / 23 신뢰성 제공을 위해 타이머 TCP는 세그먼트 그룹을 전송 할 때 재전송 타이머를 설정함. 시간 내에 ACK가 수신되지 않으면 세그먼트를 재전송 함. 자세한 내용은 14장(TCP 타임아웃과 재전송). 여기서 처음 재전송은 184 대음은 187 다음은 193 3초 6초 ,,, 늘어남. 타임아웃이 2배씩 증가함. 2019년 4월 14일 오전 2시 34분 22 / 23

3. TCP 헤더와 캡슐화 23 / 23 IP Header TCP Header TCP Data TCP Segment IP datagram 20 Bytes 31 15 16 발신지 포트 목적지 포트 순서번호 0 ~ (2^32 – 1) 확인응답번호 (seq+1) 헤더길이 예약(0) CWR ECE URG ACK PSH RST SYN FIN 윈도우 크기 TCP 체크섬 긴급 포인터 옵션 옵션 : MSS라고 하는 최대 세그먼트 크기 옵션. 교환하는 첫번째 세그먼트에서 옵션을 지정함. 긴급 포인터 : 긴급한 메시지를 보낼때 윈도우크기 : 윈도우 광고를 위해 사용됨 2019년 4월 14일 오전 2시 34분 23 / 23

4. 정리 24 / 23 TCP 신뢰성 있음 연결 지향 바이트 스트림의 전송계층 서비스 오류를 다루기 위한 방법 오류정정코드 추가 데이터 재전송 타이머를 설정하여 처리 패킷 순서 번호 표시 데이터 전송 효율 슬라이딩 윈도우를 사용하여 높임. 2019년 4월 14일 오전 2시 34분 24 / 23

Qna