2018. 10. 31. 14:31ㆍ네트워크 구조와 설계
chapter 3: Transport Layer
goal:
- 트랜스포트 서비스 이해
1) multiplexing, demultiplexing
2) reliable data transfer
3) flow control
4) congestion control
- Internet transport layer protocol
1) UDP: connectionless protocol
2) TCP: conection-oriented reliable transport, congestion control
3.1 Transport Layer Services
application Layer에서 app을 설계할 때는 transport Layer을 고려해야 한다.
1. Transport services and protocols
a) 트랜스포트 계층은 서로 다른 host (end-system)간에 logical end-to-end communication 을 제공한다.
b) transport protocols(ex. TCP, UDP)들은 end system에서 동작한다.
1) 전송면: application message를 segment로 쪼개어 network layer로 넘겨준다.
+) application - message, transport layer - segmaent
2) 수신면: 받은 segment들을 message로 reassemble(재조립)하여 application layer으로 보내준다.
c) app에서 사용할 수 있는 프로토콜은 : TCP, UDP (인터넷 측면)
2, Transport VS. Network layer
- network layer : 호스트간 logical communication. (우편함 까지)
- transport layer: 프로세스간 logical communication (목적지의 사람까지)
(신뢰성있는 암호화 같은 것)네트워크 계층의 서비스에 의존한다.
예) 12 kids in Ann's house sending letters to 12 kids in Bill's house
3, Internet transport-layer protocols
a) TCP: reliable (- flow control, sequence number, ACK/NAK, Timer 을 이용하여), in-order delivery
1) congestion control (= 한 TCP 연결이 과도한 양의 트래픽으로 통신하는 모든 호스트들 사이의 스위치와 링크를 폭주되게 되는 것을 막는 것. 링크의 대역폭을 공평하게 공유함으로써 트래픽 조절,UDP는 제공하지 않는다. )
2) flow control
3) connection setup
b) UDP: unreliable, unordered delivery
1) no-frills extension of "best-effort" delivery IP(Internet Protocol) - 군더더기가 없어서 delay가 없다.
+) IP는 통신 호스트들 간에 세그먼트를 전달하기 위해서 최대한 노력하지만, 어떤 보장도 하지 않는다는 것.
세그먼트의 순서없이, 데이터의 무결성은 보장하지 않는다.
c) 제공하지 않는 서비스
1) delay guarantees - 딜레이 보증
2) bandwidth guarantees - 대역폭 보증 L/R
3.2 multiplexing and demultiplexing
- 네트워크 계층이 제공하는 호스트 대 호스트 전달 서비스에서 호스트에서 작동하는 app에 대한 프로세스 대 프로세스 전달 서비스로 확장하는 것이다.
- demultiplexing : 전달 받은 segments에서 header를 사용하여 올바른 소켓에게 전달해주는 작업.
+) 트랜스포트 계층에서 네트워크 계층에서 받은 segment를 재조립해서 어플리케이션 계층으로 넘겨주기 위해서는 올바른 소켓(각 프로세스마다 소켓 프로세스가 있다.)에 전달해야한다. 올바른 소켓으로 전달하기 위해서는 각 세그먼트에 달려있는 헤더의 식별자 필드에 있는 식별자에 따라야 한다. demultiplexing은 트랜스포트 계층에서 이 식별자를 해석하여 올바른 소켓에 전달해주는 서비스를 이야기한다.
- multiplexing : 다양한 소켓들로부터 data를 전달하기 위해 transfer header를 더하는 작업.
+) 반대로 수신자에게 올바른 소켓에 전달해주기 위해서 세그먼트에 달리는 헤더 식별자 필드에 해당 값을 작성해주는 서비스를 말한다.
2, How demultiplexing works.
a) host들은 IP datagrams(네트워크의 packet 단위,종종 UDP의 segment를 이리 부르기도 한다.)들을 받는다
1) 각 datagram들은 source IP address, destination IP를 가지고 있다.
2) 각 datagram들은 하나의 transport-layer segment를 가지고 있다.
3) 각 segment들은 헤더로 source, destination 포트 넘버를 가지고 있다.
b) host는 IP address & port number, 이 두가지를 사용하여 올바른 소켓에게 segment를 직접 넘겨준다.
3, Connectionless demultiplexing (비연결형 역다중화) - 포트 넘버로만 식별
- UDP socket이 생성될 때, 트랜스 포트 계층은 포트 번호를 소켓에게 자동으로 할당한다. 헤더에는 트랜스포트 계층이 해석할 수 있는 두가지의 식별자가 있다. source port number & destination port number.
- UDP socket으로 보내질때 datagram을 만들어질 때 destination IP와 Port number가 있어야 한다.
4, Connection-oriented demux (연결지향형 역다중화) - 포트넘버 와 Ip address로 추가적으로 식별
a) TCP socket은 4가지 tuple을 식별해야 한다.
- source Port number
- destination Port number
- source IP address
- destination IP address
b) demux: 수신자는 적절한 소켓에 직접 segment을 주기 위해서 4가지 값을 확인한다.
c) 서버 host는 동시에 많은 TCP socket들을 제공한다. - 각 소켓은 4가지 튜플을 가지고 있다.
d) web server는 연결되는 client마다 다른 소켓을 가지고 있다. - 비지속 HTTP는 각 요청마다 다른 소켓을 가질 것이다.
- 이는 웹서버의 특징이고 persistent(지속적인) HTTP, 단 한개의 소켓으로 주고 받는가? <-- 질문 ㄱㄱ
* Thread sever
- process는 변수의 공유도 없이 독립되어 있다. 한 프로그램에서는 thread함으로써 data를 공유 가능하다.
3.3 connectionless transport: UDP
1, UDP: User Datagram Protocol [RFC 768]
- loss, delay, out order segment이지만 best effort이다. 그리하여 application에서 처리한다.
a) "no frills (delay 없는)". "bare bones"의 인터넷 transport Protocol
b) "best effort" service으로 UDP segments 는 이리 될 수 있다.
- lost : data의 잃어버림
- app으로 순서없이 전달되어질 수 있다.
c) connectionless :
- 누구에게서 왔는지는 알 필요없다. 데이터만 보내기만 하면 됨.
- TCP와 다르게 핸드쉐이킹 과정이 없다.
- 각 UDP segment들은 독립적으로 처리 된다.
d) UDP 가 사용되어 지는 것
- 멀티미디어 app 스트리밍
- DNS
- SNMP <- 네트워크 관리할 때 쓰는 프로토콜, 네트워크 혼잡시 TCP보다 핸드쉐이킹 과정이 없는 UDP가 유리, but
데이터 손실 있을 수도
e) UDP를 신뢰적인 데이터 전송을 하는 법:
=> application layer에서 신뢰성을 제공한다. 그리고 application-spectic error ercovery!
2, UDP : segment header
: UDP segment 은 헤더에 4개의 필드를 갖는다.
- Source port #
- Destination port #
- length : segment의 길이
- checksum : error check
a) UDP를 사용하는 이유
1) no connection establishment (delay를 만들 수 있는) : 핸드쉐이킹 과정이 없다.
2) simple : 송신자와 수신자에 연결 상태가 없다.
3) header size가 작다 : TCP의 헤드 사이즈는 20바이트, UDP는 4개의 필드라서 8바이트.
4) no congestion control : UDP는 원하는 빠르기만큼 항상 높일 수 있다.
3, UDP checksum
- 송신자는 checksum 필드에 16bit의 integer를 넣어서 전한다, 이는 1의 보수이다.
- 오버플로우 발생시 가장 MSB 쪽으로 올려주고 최종합의 1의 보수가 checksum이 된다.
- 패킷에 오류가 없다면, 모두 1. 있다면 0이 있다. (하지만 위치는 알수 없다.)