[CS 기초 스터디] 6주차 회의록

정규 회의록

일시 : 2022.11.25 15:00

범위 : 네트워크 4~6강

강의 : 이석복 교수님 컴퓨터네트워크 강의

활동 : github에 올린 내용 정리본 읽고 공부한 내용에 대해 발표 및 질의응답

정리 : https://github.com/GDSC-Ewha-4th/Study-CS.git

---

Transport Layer: Application Layer 아래에 존재

• application 계층에게 그 아래 작업은 블랙 박스
  • 우체통 구멍(소켓)에 편지 넣으면 편지 전송, 과정은 몰라도 됨
• Transport 계층의 프로토콜인 TCP, UDP 또한 그 아래 계층에 대해서는 블랙 박스
• Internet Layer의 IP (internet protocol) 위에서 동작

계층별 데이터 전송 단위

• application 계층의 전송 단위: Message
• transport 계층의 전송 단위: Segment
• Internet 계층의 전송 단위: Packet
• Link 계층의 전송 단위: Frame

Multiplexing / demultiplexing

transport 계층에서 제공하는 기본 기능 (TCP, UDP 모두)

• Multiplexing
  • Application layer -> Transport layer 로 전달 될 때,
    
    여러 소켓의 데이터를 모은 후 transport 계층의 header을 추가해서 Network layer로 전달
• Demultiplexing
  • Transport layer -> Application layer 로 전달 될 때,
  • 올바른 소켓으로 전달* 하는 과정
• UDP => Connectionless
  • 소켓과 소켓 사이에 1:1 매핑 개념 X
    
    => 한 기기 - 다른 기기 주고 받을 때 전용 소켓 X
  • 헤더 부분에 src port, dest port 정보 저장
• TCP => Connection O
  • 소켓과 소켓이 1:1 관계 (다른 기기에게 연결할 소켓이 지정)
  • 소켓의 id (addressing) = src: ip, port / dest: ip, port
    
    => TCP socket identified by src ip, src port, dest ip, dest port
  • 웹 서버의 프로세스
  • 클라이언트로부터 TCP connection => accept => 새 소켓의 id를 리턴
  • 클라이언트와 유일한 소켓이 생성, 각자를 위한 소켓

UDP

• UDP Segment = header + data(payload)
  • data = application 계층의 message
  • header = src port, dest port, length, checksum
    
    (해당 전송 단위의 헤더를 알면 그 프로토콜을 알 수 있음)
    • port: 알맞은 소켓 찾아가라고 .. (=> multiplexing/demultiplexing 하려고)
• header의 크기: 32bit
  • 각 포트 번호 크기: 16 bits -> 한 기기에서 2^16개의 포트 사용 가능 (적당)
    
    사용 가능 포트 개수 <--trade off--> 오버 헤드 문제
  • checksum: 전송 중 data 부분에 에러가 발생했는지 확인 (parity bit)
  • length: 헤더를 포함한 segment의 크기
• no connection (sender, receiver 간에)
  • -> no delay, simple
• 작은 헤더 사이즈 -> 다양한 기능 X
• congestion control X (혼잡 컨트롤 X)

reliable data transfer

=> TCP에서 제공하는 중요 기능

• machine A의 TCP 소켓(sender) --> machine B의 TCP 소켓(receiver)
  
  underlying network의 중간 라우터들을 거치면서 unreliable 가능성 있음
  
  unreliable: Error 또는 Loss 발생 => 이를 처리하면 reliable

RDT (Reliable Data Transfer protocol)

-> TCP를 이해하기 위한 가상의 프로토콜 가정

Error 처리

• error detection - feed back
  • receiver의 피드백: ACKs(에러 X), NAKs(에러 O)
    
    => TCP segment의 header의 checksum을 통해 에러 체크
    
    (UDP는 ACK, NAK X -> unreliable)
  • receiver: checksum으로 error detection -> ACK/NAK, sender: NAK을 받으면 재전송
• sequence number
  • 만약 ACK/NAK이 corrupted(손상된) 상태로 도착 -> sender은 receiver에게 무슨 일이 있는지 모름
  •  

무조건 retransmit -> 중복

• •  
  • sender는 header에 sequence number을 붙인 패킷 전송
  • receiver는 패킷의 seq num으로 중복 패킷인지 판단 (중복 -> 폐기)
• NAK free
  • receiver은 무조건 ACK을 보냄 (+정상적으로 받은 마지막 패킷의 seq num)

Loss 처리

• Timer - 패킷 전송 후 피드백(ACK)이 일정 시간 안 오면 재전송
  • 너무 짧음 -> Loss 발생 시 빠른 재전송, 하지만 피드백이 늦게 온 지연의 경우 불필요한 재전송
  • 너무 긺 -> Loss 발생 시 느린 재전송, 지연의 경우 그만큼 피드백을 기다리는 충분한 시간(불필요한 재전송 X)
  • 패킷 loss == 피드백 loss (sender는 둘 다 피드백을 못 받았음)
  •  

sender: timeout 이후 마지막으로 받은 ack 이후의 패킷을 send

• •  
  • 지연의 (premature timeout & delayed ACK)
    • 이미 timeout으로 인해 중복 패킷을 전송, 직후에 피드백
    • 

TCP

특성

• point to point: machine의 프로세스마다 각각의 소켓(TCP) (+상대 machine의 소켓 => 한 쌍의 소켓 (1:1 관계로, unique))
• reliable: in-order byte stream
• pipelined
• full duplex
• connection-oriented
• flow control
  • application에서 데이터를 보내는 속도와 다르게, TCP -> network layer로 패킷을 보내는 속도는 조절 (상대방 machine)
• congestion conrtol
  • 중간 network 상황 고려

RTT (Round Trip Time)

• segment를 보낸 후 그에 대한 ACK이 돌아올 때까지의 시간 (sample RTT)
• network 상황마다 (=>라우터의 queuing delay에 따라) 달라짐
• EstimatedRTT = (1-a) * EstimatedRTT + a * sampleRTT (최신RTT가 더 많이 반영)
• timer의 timeout 설정의 근거: TimeoutInterval = EstimatedRTT + margin(여유)

각 TCP 소켓(참고: 한 machine에는 여러 프로세스, 각 프로세스의 클라이언트마다 소켓 생성)에는 send buffer, rcv buffer 존재

• sender 버퍼 -> receiver 버퍼
• 한 번에 여러 개의 segment를 보냄
• segment 크기: 200byte -> seq num은 #0, #200, #400, ..

sent ACKed: send 후 ACK까지 받음 -> window가 slide (더 이상 필요 X)

sent, not yet ACKed(in-flight): send, but yet ACK X

usable, not yet sent: 아직 안 보냄

not usable