OSI 7계층

컴퓨터 네트워크 프로토콜 디자인과 통신을 계층으로 표현한 모델

• 통신 과정을 개념적으로 나누면 문제 해결 시 특정 부분에 집중할 수 있음

계층	기능	단위(PDU)	예시
7. 응용(Application)	사용자와 상호작용하여 응용 서비스 수행	데이터	프로토콜: HTTP/HTTPS, FTP, DNS, SMTP, SSH
6. 표현(Presentation)	주고 받는 데이터의 형식(Syntax)을 지정 (문자 인코딩, 직렬화 등)	데이터	표현 형식: JPEG, MPEG, XML
5. 세션(Session)	지속적인 정보 교환을 위해 연결의 문맥을 관리 (인증, 인가 등)	데이터
4. 전송(Transport)	서로 다른 호스트의 포트 간(port-to-port)에 연속적으로 데이터 전송 (연결 지향 통신, 신뢰성 보장, 흐름 제어 등)	세그먼트(TCP), 데이터그램(UDP)	프로토콜: TCP, UDP
3. 네트워크(Network)	서로 다른 네트워크의 호스트 간(host-to-host)에 데이터 전달 (패킷 포워딩과 라우팅)	패킷	프로토콜: IP
2. 데이터 링크(Data link)	같은 네트워크 내 노드 간(node-to-node)에 MAC 주소로 정보 송수신	프레임	프로토콜: MAC(Ethernet, Wi-Fi)
1. 물리(Physical)	기기와 물리 전송 매체 간의 전기적 신호 전달	비트

• 노드(Node): 로컬 네트워크에 연결된 컴퓨터나 장비들 (MAC 주소로 구분)
• 호스트(Host): 네트워크에 연결된 컴퓨터나 장치들 (IP 주소로 구분)
• 포트(Port): 호스트의 운영 체제에서 네트워크 통신을 하고 있는 프로세스를 식별하기 위해 사용하는 값 (포트 번호로 구분)

소켓(Socket)

프로세스가 네트워크 통신을 위해 생성하는 창구 (통신 프로토콜 + IP 주소 + 포트 번호로 구분)

• 일반적으로 서버는 정해진 특정 포트 값을 사용하고, 클라이언트는 무작위 포트 값을 사용하여 통신함
• 이때 서버에서는 통신 하나에 소켓을 하나씩 생성하여 가짐 (socket() 시 포트 점유, accept() 시 소켓 생성)
• 따라서 서버는 동일 포트로 여러 소켓을 가짐
  • 서버의 최대 접속 가능 수는 이론적으로 무한함 (클라이언트의 주소로 소켓을 식별할 수 있으므로!)

TCP

전송 제어 프로토콜: 안정적인 통신을 제공하는 프로토콜

• 3계층의 IP를 기반으로 함 (따라서 TCP/IP라고 많이 부름)
• 연결 지향적임 (연속적인 데이터 전달을 위해 서버와 클라이언트 간 연결을 맺음)
• 통신의 신뢰성을 보장함 (reliable)
  • 데이터 전송 순서 보장 (in-order)
  • 유실된 패킷 재전송(retransmit)
  • 흐름 제어(Flow control): 송신자가 데이터를 지나치게 빨리 보내지 않도록 조절
  • 혼잡 제어(Congestion control): 혼잡 상태를 파악하고 패킷 전송량을 조절
• 사용 예시: FTP, SSH, SMTP, HTTP

3-way handshake

TCP의 연결 성립 과정

1. 클라이언트가 서버로 SYN 전송
2. 서버가 클라이언트로 ACK + SYN 전송
3. 클라이언트가 서버로 ACK 전송

왜 3-way일까?: 양방향이기 때문에 서버도 클라이언트를 알아야 함

• 자신을 알리는 SYN과 응답하는 ACK이 두 쌍, 그 중 ACK+SYN으로 한 번의 통신을 아낌

4-way handshake

TCP의 연결 종료 과정

1. 클라이언트가 서버로 FIN 전송
2. 서버가 클라이언트로 ACK 전송
3. 서버에서 CLOSE_WAIT 후 클라이언트로 FIN 전송
4. 클라이언트가 서버로 ACK 전송, 서버는 ACK을 받으면 종료
5. 클라이언트는 TIME_WAIT 후 종료

왜 4-way인가?: 서버에서 CLOSE_WAIT 단계가 필요하기 때문

• CLOSE_WAIT: 서버 애플리케이션에서 close()가 호출되는 것을 기다리는 상태
• 서버 애플리케이션이 정상적으로 연결을 종료하도록 기다려줌

왜 TIME_WAIT이 필요한가?: 아직 전송 중인 패킷이 있을 수 있음

• 연결을 즉시 종료하면, 바로 통신을 다시 시작했을 때, 이전 연결에서 보냈던 패킷이 뒤늦게 도착할 수 있음
  • 이때 이 패킷을 수리하면 데이터 무결성 문제가 발생할 수 있음
  • 따라서 연결 종료 전에 일정 시간만큼 대기하여 문제를 예방함
• 클라이언트가 전송하는 마지막 ACK이 유실될 수도 있음
  • 서버는 LAST_ACK 상태로 유실된 ACK을 기다리며, 연결을 종료하지 못 함
  • 이때 클라이언트가 새로운 통신을 다시 연결하면 문제가 발생함

흐름 제어(Flow control)

송신자의 전달 속도가 수신자를 압도하지 않도록, 데이터 전달 속도를 제어

• 수신 측 큐 용량 초과 시 패킷이 유실되며, 패킷이 유실되면 이를 재전송해줘야 함

TCP의 흐름 제어 방식:

• Sliding window: 윈도우에 포함된 패킷을 모두 전송하고, ACK을 받은 만큼 윈도우를 움직임
  • Stop-and-wait: 윈도우의 크기가 1, 하나씩 받고 기다림
    • 가장 간단한 구현 방식
  • Go-Back-N: N번 패킷이 유실되면 N번부터 재전송
    • 패킷 유실이 빈번하면 비효율적
  • Selective repeat: 받지 못 한 패킷만 재전송을 요구함
    • 순서와 다르게 받은 패킷들을 저장해둘 수 있어야 함

혼잡 제어(Congestion control)

송신자의 전달 속도가 네트워크를 압도하지 않도록, 데이터 전달 속도를 제어

• 혼잡 붕괴(Congestive collapse): 트래픽이 대역폭을 초과할 때, 혼잡 상태로 인해 수신자가 패킷을 받지 못 하고, 패킷 유실이 발생하여 여러 송신자들이 재전송을 반복하는 현상
  • 이를 막기 위해서는 송신자들이 혼잡 상태를 파악하고 패킷 전송량을 줄여야 함

TCP의 혼잡 제어 방식:

• Slow start: 윈도우 크기를 지수적으로 증가시킴 (1, 2, 4, ...)
  • ssthresh(slow start threshold) 값까지만 적용, 이후에는 AIMD로 작동
• AIMD(Additive increase/multiplicative decrease): 윈도우의 크기를 1씩 증가시키다 전송이 실패하면 2배로 줄임
• 중간 패킷이 손실되면 중복된 ACK 전송, 중복된 패킷을 세 번 받으면 혼잡으로 간주함
• 혼잡 감지 시, TCP 알고리즘마다 고유의 방법으로 대응함
  • Fast retransmit: 혼잡 감지 시, ssthresh 값을 현재 윈도우의 반으로 줄이고 윈도우를 1로 줄임
    • 처음으로 돌아가서 Slow start 과정을 밟음
    • TCP Tahoe의 방식임
  • Fast recovery: 혼잡 감지 시, 윈도우의 크기를 반으로 줄이고 ssthresh 값을 해당 값으로 설정함
    • 따라서 Slow start 과정을 건너뜀
    • TCP Reno의 방식임

UDP

신뢰성을 보장하지 않는 대신 속도가 빠른 프로토콜

• 데이터의 전달과 전달 순서, 중복 보호를 보장하지 않음
• 연결을 맺지 않으므로 핸드셰이킹이 필요 없음
• 재전송을 기다리지 않고, 못 받은 패킷은 그냥 버리고 시간을 아낌
• 사용 예시: DNS, DHCP (통신이 단순하고 속도가 우선인 경우 사용)

DNS

도메인 네임 시스템: 도메인 이름와 네트워크 주소 간의 변환을 위한 시스템

DNS 쿼리 예시

예시: "www.google.com"을 IP 주소로 변환

1. PC → Local DNS 서버 (e.g. ISP)
2. Local DNS 서버 ↔ Root DNS 서버 (.com DNS 서버 주소 제공)
3. Local DNS 서버 ↔ .com DNS 서버 (google.com DNS 서버 주소 제공)
4. Local DNS 서버 ↔ google.com DNS 서버 (www.google.com의 IP 주소 제공)
5. PC ← Local DNS 서버 (IP 주소 제공 및 캐싱)