3.1 transport layer services

transport services and protocols

트랜스포트 레이어가 하는 일

• 서로 다른 호스트에서 돌아가는 어플리케이션 프로세스 간 logical communication을 제공한다.
• 프로토콜은 엔드 시스템에서 돌아간다
  -> 코어에 있는 라우터들은 트랜스포트 레이어를 구현하고 있지 않음.(라우터들을 거쳐 데이터들이 전달되지만 트랜스포트 레이어의 입장에서는 거쳐가는 과정은 보이지 않고 두 엔드 시스템 사이의 logicla한 커뮤니케이션만 보게 됨)(라우터에서는 실제로 네트워크, 데이터 링크, 피지컬 레이어만 존재)
  -> sender가 하는 일 : segment 단위로 메세지를 잘라서 트랜스포트 레이어의 헤더를 붙이고 네트워크 레이어로 보내줌
  -> receiver가 하는 일 : 세그먼트들을 합쳐서 메세지를 만들고 어플리케이션 레이어로 전달
• TCP / UDP

Transport vs network layer

• network layer : 호스트 사이의 logical communication(통신)
• transport layer : 프로세스 사이의 logical communication

(참고)
호스트 -> 디바이스. ip주소를 가지고 있음
프로세스 -> 호스트 위에서 돌아가는 여러가지 프로세스들

Internet transport layer protocols

• TCP : reliable(신뢰성 있게 전달, 보낸 그대로 도착하도록), in-order delivery(보낸 순서대로 받는사람이 받음)
  -> 전송 속도 조절(congestion control, flow control)
  -> 커넥션을 맺어야 통신이 가능하다.(connection setup)
• Udp : unreliable(신뢰성x, 중간에 날아갈 수 있음), unordered delivery(보낸 순서 상관 없이 도달)
  -> 그저 전달 역할만 수행한다.
• 두 서비스 모두 안해주는 것들
  -> 딜레이 보장 : 언제까지 도달하도록 보장 해주는것.
  -> 속도 유지 보장(bandwidth guarantee) : 예를들어 스트리밍 중에 계속 몇bps로 속도를 유지하도록 해 주는것.
  —> tcp와 udp모두 둘다 보장 안해줌

3.2 multiplexing and demultiplexing

multiplexing / demultiplexing

서버 컴퓨터 하나에 두개의 서버가 돌아가는 상황
-> 네트워크 레이어는 ip 주소를 보고 가기 때문에 두 클라이언트 모두 한 서버로 가고, TCP가 두 프로세스 중 어느 프로세스로 갈지 결정해 주는 역할을 한다.
-> sender에서의 multiplexing : 여러 소켓에서의 데이터를 다루기 위해 트랜스포트 헤더를 붙여서 보내준다.
-> receiver에서의 demultiplexing : 헤더를 보고 어느 소켓으로 보낼 지 결정한다.

connectionless demultiplexing -> UDP

• 서버에서의 동작

1. 소켓 생성
2. 서버의 addr 정보를 넣어주고 바인드 해줌
3. 소켓으로 부터 메세지 읽어 들임(recvfrom) -> 클라이언트의 정보를 저장
4. 클라이언트쪽으로 메세지 보냄(sendto) -> 앞서 저장한 클라이언트의 정보로 보냄

• 클라이언트에서의 동작

1. UDP 소켓 생성
2. 서버의 정보 저장
3. Sendto
4. Recvfrom
   -> 서버와 클라이언트 둘 다 tcp와 달리 커넥션 맺고 끊는게 없다.

• UDP 패킷을 보낼 때 목적지 주소와 포트번호를 정해줘야 한다.
  -> 서버가 UDP 패킷을 받으면 헤드에 포함된 목적지의 포트 번호를 확인하고 이 포트 번호를 사용하는 소켓으로 보내줌.
• 같은 목적지 주소와 같은 목적지 포트 번호를 가지고 있는 패킷은 같은 소켓으로 보내진다.
  -> 보내는 쪽의 주소와 포트 넘버가 달라도 이렇게 동작함.

connection-oriented demultiplexing -> TCP

• TCP는 소켓을 구별하기 위해 네가지 정보를 모두 사용한다.(네 정보 모두 일치해야 같은 소켓으로 전달됨)
  -> 커넥션을 맺기 때문에 가능함.(커넥션이 없으면 누가 나에게 보냈는지 모르고, 커넥션이 있으면 receiver입장에서 sender의 정보가 확실하니까 목적지가 같더라도 source가 다르면 다른 소켓으로 취급)
  -> surce ip address / source port number / destination ip address / destination port number
• TCP 에서의 demux : receiver는 네가지 정보를 모두 활용하여 segment를 적절한 소켓으로 전달해 준다.
• 웹 서버는 TCP를 사용하는데, 클라이언트와 커넥션을 맺을 때 마다 다른 소켓을 사용한다.
  -> 사용하는 포트번호와 ip 주소가 같더라도 source의 정보들이 다르기 때문
  -> non-persistent HTTP는 요청마다 새 커넥션을 하기 때문에 모두 다른 소켓을 사용한다.

3.3 connectionless transport : UDP

UDP : User Datagram Protocol

• no frills, bare bones 라고 불리는 인터넷 트랜스포트 프로토콜이다.
• best effort 서비스이다.
  -> 최선을 다하긴 하는데 보장해 주지는 않는다.(최선만 다함)
  -> UDP segment들은 손실될수도, 순서가 바뀔수도 있다.
• connectionless(커넥션이 없다)
  -> UDP sender와 receiver 사이의 hanshaking이 없다.
  -> 각각의 UDP segment(메세지)들이 독립적으로 처리된다.
• UDP는 언제 사용하는가?
  -> streaming multimedia apps : 손실이 일어나도 되고, 속도가 중요한 경우
  -> DNS : 한번 사용하고 끊기 때문
  -> SNMP
• reliable transfer over UDP : UDP 위로 reliable을 옮겼다(어플리케이션 레이어에서 reliaility를 만들겠다.)
  -> TCP를 사용하면 reliable 기능 중복되기 때문에 UDP를 사용하고 어플리케이션 레이어에서 reliability를 구현
  (참고)
  http는 보통 tcp를 사용하는데(http 버전 1.0, 1.1, 2) 요즘 나오는 http/3은 QUIC를 사용한다.
  -> QUIC는 트렌스포트 레이어의 새로운 서비스 인데 UDP 위에 기능들을 추가해서 만든 서비스 이다.

UDP : segment header

• 어플리케이션 메세지를 segment들로 나눈다.
• 헤더와 payload(데이터) 부분으로 나눈다.
• 헤더 : 8바이트(한줄에 32bit = 4byte 이므로 두줄로 구성)
  -> 첫줄에 source, dest 의 포트번호(ip 주소는 네트워크 레이어의 ip헤더에 있음)
  -> 둘째줄에 전체 segment의 길이(헤더 + payload)와 checksum(에러 correction을 위해 있음)
  -> segment의 길이 : 16비트 -> 0 ~ 2^16-1 = 65535, 이 중 헤더의 길이가 8이므로 최대 payload의 길이는 65527

왜 UDP를 사용하는가?

• 커넥션 맺을 필요 없음(딜레이 없음)
• 간단하다
• 헤더 사이즈가 작다(tcp는 20바이트)
• 보낼 수 있을 만큼 빠르게 보냄(tcp는 속도 조절함)

UDP checksum

• checksum의 목적 : 전송된 segment에 대해 오류 판단
• sender
  -> 세그먼트의 내용들을(헤더 + payload) 16비트로 나눠서 관리한다.
  -> 16비트의 수들을 다 더해 checksum에 저장한다.(1의 보수 사용)
• receiver
  -> 받은 세그먼트에 대한 checksum을 계산한다.
  -> 받은 세그먼트를 16비트씩 나눠서 다 더해서 checksum과 비교
  -> cheksum과 다르면 에러로 판단, 같으면 에러 없다고 판단
  -> 그런데 checksum이 같다고 에러가 없다는 것을 의미하는것은 아니다.(특정 부분에서 빠지고, 다른 부분에서 더해지면 총 합은 같기 때문)

예시

• 16비트가 두개만 있다고 가정
• 두개를 더한다
  -> 자리수가 올라가면 wrap around(앞의 1을 맨 뒤에 더해줌) 해준다
  -> 체크섬에는 1의 보수 취해서 저장(0,1 바꿔서)

UDP checksum calculation(실제 동작 과정)

checksum을 일단 0으로 해 둔다.
-> ip pseudo 헤더 부분까지 포함하여 checksum을 계산해서 저장한다. (ip는 네트워크 레이어의 도움을 받아야함)
-> 중간에서 끝나면 16비트 만큼 나머지 0으로 채워준다.(16비트로 나누는데 앞에서 끝나버리면 나머지 부분들은 0으로 채워줌)

출처 및 참고
Computer Networking A Top-Down Approach 7-th Edition / Kurose, Ross / Pearson
서강대학교 기초컴퓨터네트워크 강의자료