=== Transport Layer ===
1. transport layer servies
- provide logical communication between application processes running on different hosts : 서로 다른 호스트에서(기기) 작동중인 application process 사이의 logical communication을 제공한다.
- transport protocols run in end systems : end system 에서 동작한다.
- sender side: breaks application messages into segments, passes to network layer : sender는 데이터를 segment 단위로 거기에 header을 붙인다. 그리고 네트워크 레이어로 내린다.
- receiver side: reassembles segments into messages, passes to application layer : segment들을 결합, application layer로 올려준다.
- more than one transport protocol available to applications : 한 개 이상의 transport protocol을 선택가능
- Internet: TCP and UDP
(요약)
Transport services and protocols
서로 다른 호스트에서(기기) 작동중인 application process 사이의 logical communication을 제공한다.
-
sender side: sender는 데이터를 segment 단위로 거기에 header을 붙인다. 그리고 네트워크 레이어로 내린다.
-
receiver side: segment들을 결합, application layer로 올려준다.
Transport vs. network layer
- network layer: logical communication between hosts : 호스트간의(기기) logical communication
- transport layer: logical communication between processes : 프로세스(호스트 위에서 돌아가는 것들) logical communication
- relies on network layer services
예를 들어 집이 호스트고 아이들이 프로세스이다. app message는 편지이다.
transport protocol : 앤과 빌이 편지를 모아서 우편함에 넣는다. 또 편지가 오면 받을 사람에게 나누어 준다.(demux)
network-layer protocol : 우편 서비스
(요약)
Internet transport layer protocols
- reliable, in-order delivery (TCP) : 메세지를 신뢰선 있게 전달, 보낸 순서대로 받음
- congestion control
- flow control
- connection setup : 커넥션 필수
- unreliable, unordered delivery (UDP) : 비신뢰 전달, 순서없이 전달
- no-frills extension of "best-effort" IP : 기본역활에 충실
- services not available
- delay guarantees : 딜레이가 적도록 보장불가
- bandwidth guarantee : 속도유지 보장불가
(요약 - 중요)
TCP
- reliable, in-order delivery (TCP) : 메세지를 신뢰선 있게 전달, 보낸 순서대로 받음
- congestion control
- flow control
- connection setup : 커넥션 필수
UDP
- unreliable, unordered delivery (UDP) : 비신뢰 전달, 순서없이 전달
- no-frills extension of "best-effort" IP : 기본역활에 충실
- services not available
- delay guarantees : 딜레이가 적도록 보장불가
- bandwidth guarantee : 속도유지 보장불가
2. multiplexing and demultiplexing
P3 가 client로써 서버에서 정보를 가지고 와야 하는 상황
P1이 web server, P2가 SSH server라고 하자
P3은 web browser, p4가 ssh client
근데 이 서버가 web과 ssh를 모두 지원한다고 하자 하지만 network layer에서는 ip만 보기 때문에 application의 어디로 갈지를 transport가 결정하게 된다.
메세지를 반활할때는 transport layer는 header을 data 앞에다 붙여준다.(multiplexing) 이는 나중에 받는 쪽에서 demultiplexing을 하기 위함이다.
그럼 network layer에서는 ip주소만 보고 다시 보내준다.
반대로 메세지를 받았을때 패킷을 demultiplexing하여서 애플리케이션 계층에 보내준다.
(요약)
내려갈때 multiplexing
올라갈때 demultiplexing
Connectionless demultiplexing(UDP)
우선 socket을 만든다. SOCK_DGRAM은 UDP를 나타낸다.(SOCK_STREAM : TCP)
bind를 하기 위해서 server의 address정보를 넣어준다.
AF_INET : IPv4
INADDR_ANY : 자기자신의 ip번호
htons(PORT) : 앞에서 8080번 포트로 설정해 놓았다.
recvfrom : 소캣으로부터 메세지를 읽어드린다.
sockfd : 읽어드리는 소켓
cliaddr : 메세지 안에 client에 대한 정보
sendto : 클라이언트쪽으로 정보를 보낸다.
hello : 보내고자 하는 문자열
cliaddr : 클라이언트에 대한 정보로 메세지를 보낸다.
servaddr에 서버에 대한 정보를 받아온다.
sendto : 서버쪽으로 정보를 보낸다.
servaddr : 서버 정보에 hello를 보낸다.
recvfrom : 소켓에 서버로 부터 온 정보를 받는다.
- When server receives a UDP packet : 수신자가 UDP 패킷을 받을떄 하는 일
- checks destination port number in the packet : 목적지 포트번호가 있음
- directs UDP packet to socket with that port number :
- Packets with the same destination address and destination port number will be directed to the same socket : 같은 주소 같은 포트은 같은 소켓으로 전송될 것이다.
- Even when source address and source port number is different
서버에서 6428번 포트의 소켓으로 패킷을 받게 된다.
Connection-oriented demultiplexing(TCP)
- TCP socket identified by 4-tuple : 아래의 4개가 모두 같아야 같은 소켓으로 전달된다.
- source IP address : IP 주소
- source port number : 포트 번호
- destination IP address : 목적지 IP 주소
- destination port number : 목적지 포트 번호
- demux: receiver uses all four values to direct segment to appropriate socket : 4개의 정보를 가지고 정보가 모두 일치하는 포트로 전달해준다.
- server host may support many simultaneous TCP sockets
- each socket identified by its own 4-tuple
웹서버가 TCP를 사용할떄 클라이언트가 올때마다 새로운 소켓을 만들어 주는데 각자 같은 포트를 써도 되는건가?
- web servers have different sockets for each connecting client : 클라이언트별로 ip와 포트번호가 달라서 구분이 가능하다.
- non-persistent HTTP will have different socket for each request : request할때마다 TCP connection을 새로 만든다.
(요약)
- TCP socket identified by 4-tuple : 아래의 4개가 모두 같아야 같은 소켓으로 전달된다.
- source IP address : IP 주소
- source port number : 포트 번호
- destination IP address : 목적지 IP 주소
- destination port number : 목적지 포트 번호
- demux: 4개의 정보를 가지고 정보가 모두 일치하는 포트로 전달해준다.
Connection-oriented demux: example
패킷을 보내면 source IP, port를 보고 다른 소켓으로 전달해준다.
=== connectionless transport: UDP ===
1. UDP: User Datagram Protocol [RFC 768]
- "no frills", "bare bones" Internet transport protocol : 가장 기본적인 transport 프로토콜
- "best effort" service, UDP segments may be : 최선은 다하지만 보장은 해주지 않는다.
- lost : 손실가능
- delivered out-of-order to application : 보낸순서와 다르게 전달 가능
- connectionless : 연결없이 전송만
- no handshaking between UDP sender and receiver : handshaking 없음
- each UDP segment handled independently of others : 각 UDP segment가 따로따로 처리된다.
- UDP use
- streaming multimedia apps (loss tolerant, rate sensitive) : 데이터를 잃어도 되고 속도가 더중요한 경우
- DNS
- SNMP
- reliable transfer over UDP : realiable이 필요하기는 한데 내가 realiability를 만들때
- add reliability at the application layer
- application-specific error recovery
- add reliability at the application layer
(요약)
- 가장 기본적인 transport 프로토콜
- 최선은 다하지만 보장은 해주지 않는다.
- lost : 손실가능
- delivered out-of-order to application : 보낸순서와 다르게 전달 가능
- connectionless : 연결없이 전송만
- handshaking 없음
- 각 UDP segment가 따로따로 처리된다.
- UDP use
- DNS
- SNMP
UDP: segment header
application msg는 세그먼트로 나눈다. 이때 application data(=payload)를 한 세그먼트로 나눈것이다. 그리고 나머지 부분을 header라고 부른다.
UDP header은 가로 32bit씩 총 8byte를 사용하게 된다. 이때 첫줄에는 source port와 dest post를 적게되어 있다. 두번째 줄은 length(세그먼트 길이 = 헤더와 페이로드 총합, 2^16 - 1까지 표현 가능), checksum은 에 error correction 때문에 있다.
UDP가 존재하는 이유
- connection이 없다.(딜레이가 없다)
- 간단하다
- 헤더 사이즈가 작다(TCP는 20byte)
- congestion control이 없다.
(요약)
UDP가 존재하는 이유
- connection이 없다.(딜레이가 없다)
- 간단하다
- 헤더 사이즈가 작다(8byte, TCP는 20byte)
- congestion control이 없다.
UDP checksum
간단한 에러체킹 도구
- sender
- treat segment contents, including header fields, as sequence of 16-bit integers: 모든 콘텐트를 16bit로 나눈다.
- checksum: addition (one's complement sum) of segment contents : 16bit로 나뉜 수들을 다 더한다. -> 이 값들이 checksum에 들어간다.
- sender puts checksum value into UDP checksum field
- receiver
- compute checksum of received segment
- check if computed checksum equals checksum field value : 받은 checksum과 현재 더한 값들과 같은지 확인하고 에러처리한다.
- no - error detected
- yes - no error detected
- yes does not mean there is no error in the segment : 반드시 맞다고 에러가 아니지는 않다.
(요약 - 중요)
- sender
- 모든 콘텐트를 16bit로 나눈다.
- checksum : 16bit로 나뉜 수들을 다 더한다. -> 이 값들이 checksum에 들어간다.
- receiver
- compute checksum of received segment
- check if computed checksum equals checksum field value : 받은 checksum과 현재 더한 값들과 같은지 확인하고 에러처리한다.
- no - error detected
- yes - no error detected
- yes does not mean there is no error in the segment : 반드시 맞다고 에러가 아니지는 않다.
Internet checksum: example
두개의 16비트를 다 더한다.
자릿수가 올라가면 다시 1을 처음에 더해주어서 sum을 구한다.
checksum은 sum의 1의 보수 값을 구한다.
이렇게 하는 이유는 receiver가 다시 sum을 구한다음 checksum과 sum을 더해서 그 총합이 0이 나오는지 확인한다.
UDP checksum calculation
UDP 패킷의 구조
위의 3줄은 ip헤더와 일치하지 않은 pseudo header라고 하는 ip헤더에서 데이터 몇개를 가지고 와서 넣은 것이다.
먼저 checksum을 0으로 채운다. 그리고 우선 pseudo header의 sum을 가지고 checksum을 채운다.
그러다 만약 중간에 data가 중간에 끊기게 되면 16bit의 남은 부분을 0으로 채워준다.(padded) 그리고 다시 계산하고 보수 취하고 checksum에 저장한다.
(요약)
receiver은 받은 데이터들(16bit로 나눈것, checksum)을 가지고
16bit로 나눈걸 다 더하고 최종 checksum까지 합쳐서 더해서 그 결과가 1이면 에러가 아닌것이다.
물론 에러가 나도 수정은 안하고 알려는 줄 수 있다.
