Chapter5(2). 네트워크 - 4 전송 계층 - TCP와 UDP | 5 응용 계층 - HTTP의 기초

4 전송 계층 - TCP와 UDP

포트를 통한 프로세스 식별

• IP 주소와 MAC 주소는 패킷을 송수신하는 호스트를 특정할 수 있습니다. 그런데 사실 패킷의 최종 송수신 대상은 호스트가 아니라 호스트가 실행하는 프로세스입니다. 프로세스는 포트 port 번호를 통해 식별할 수 있습니다.
  • 즉, IP 주소와 포트 번호의 조합을 통해 ‘특정 호스트가 실행하는 특정 프로세스’를 식별할수 있습니다.
• 포트 번호는 개발자가 자주 다루는 정보 중 하나이므로 조금 더 자세히 알아 두는 것이 좋습니다.
  • 16비트로 표현할 수 있는 포트 번호의 총 개수는 2의16승 , 즉 65536개입니다.
  • 0번부터 할당되므로 0번부터 65535번까지의 포트 번호를 할당할 수 있죠.
  • 그리고 65536개의 포트 번호는 번호의 범위에 따라 3가지 종류로 나뉩니다.
    • 각각 ‘잘 알려진 포트’, ‘등록된 포트’, ‘동적 포트’입니다.
      • 남은 포트 번호 49152번부터 65535번까지는 사설 포트 private port 또는 임시 포트 ephemeral port 라고도 불리는 동적 포트 dynamic port 로, 비교적 자유롭게 사용 가능한 포트 번호입니다.

포트 종류 : 잘 알려진 포트, 등록된 포트, 동적 포트

잘 알려진 포트 번호와 등록된 포트 번호

NAT와 NAPT

• 네트워크 내부에서 사설 IP 주소를 사용하는 호스트가 네트워크 외부에 있는 호스트와 패킷을 주고받기 위해서는 공인 IP 주소와 사설 IP 주소 간 변환이 필요합니다.
  • 이때 사용되는 기술이 바로 NAT (Network Address Translation )입니다
  • 서로 다른 사설 IP 주소가 같은 공인 IP 주소로 변환되더라도 다른 포트 번호로 변환된다면 네트워크 내부의 호스트를 특정할 수 있습니다.
• 가령 ‘1.2.3.4’라는 동일한 공인 IP 주소로 변환되더라도 포트 번호 6200번 으로 변환되는지, 6201번으로 변환되는지에 따라 내부 IP 주소를 구분할 수 있습니다.
  • 이처럼 IP 주소 변환 과정에서 변환할 IP 주소의 쌍과 더불어, 포트 번호도 함께 고려하는 포트 기반의 NAT를 NAPT (Network Address Port Translation )라고 합니다
    
    

 

(비)신뢰성과 (비)연결형 보장

 

• TCP는 신뢰할 수 있는 프로토콜이자 연결형 프로토콜이고, UDP는 신뢰할 수 없는 프로토콜이자 비연결형 프로토콜입니다.
• TCP
  • 신뢰할 수 있는 통신 연결형 통신
  • 상태 관리, 흐름 제어, 오류 제어, 혼잡 제어 제공 ◯ 연결 수립, 종료 과정 ◯
• UDP
  • 신뢰할 수 없는 통신 비연결형 통신
  • 상태 관리, 흐름 제어, 오류 제어, 혼잡 제어 제공 × 연결 수립, 종료 과정 ×
    
    

 

TCP의 연결부터 종료까지

➊ [송수신 방향 A → B] SYN 세그먼트 전송
➋ [송수신 방향 B → A] SYN + ACK 세그먼트 전송
➌ [송수신 방향 A → B] ACK 세그먼트 전송

 

TCP의 오류·흐름·혼잡 제어

➊ 재전송을 통한 오류 제어

• TCP는 송수신 과정에서 잘못 전송된 세그먼트가 있을 경우, 이를 재전송하여 오류를 제어합니다.
• 여기에는 크게 2가지 상황이 있습니다.
  • 하나는 중복된 ACK 세그먼트가 도착했을 때이고, 다른 하나는 타임아웃이 발생했을 때입 니다.

➋ 흐름 제어

• TCP의 흐름 제어 flow control 는 이처럼 수신 호스트가 한 번에 받아 처리할 수 있을 만큼만 전송하는 것을 의미합니다.
  • 즉, 흐름 제어는 송신 호스트가 수신 호스트의 처리 속도를 고려하며 송수신 속도를 균일하게 맞추는 기능입니다.
• TCP 헤더를 보면 윈도우(window )라는 필드를 볼 수 있습니다.
• 이 윈도우 필드에는 수신 호스트가 한 번에 처리할 수 있는 수신 윈도우 receiver window 크기가 명시됩니다

 

➌ 혼잡 제어

• 혼잡 congestion 이란 많은 트래픽으로 인해 패킷의 처리 속도가 느려지거나 유실될 수 있는 상황을 의미 합니다.
• 흐름 제어의 주체가 수신 호스트였다면 혼잡 제어의 주체는 송신 호스트입니다
• 송신 호스트는 중복된 ACK 세그먼트가 도착했을 때, 그리고 타임아웃이 발생했을 때 ‘현재 네트워크가 혼잡할 수 있다’고 판단하게 됩니다.
• 네트워크의 혼잡 가능성을 검출한 송신 호스트는 전송할 수 있는 최대 전송량을 송신하는 것이 아니라 ‘혼잡 없이 전송할 수 있을 정도의 양’만큼만 송신하게 됩니다.
  • 이 ‘혼잡 없이 전송할 수 있을 정도의 양’의 값을 혼잡 윈도우 congestion window 라고 합니다.
• 가장 기본적인 혼잡 제어 알고리즘으로는 AIMD 가 있습니다.
  • AIMD Additive Increase/Multiplicative Decrease 를 번역하면 ‘합으로 증가, 곱으로 감소’라는 의미인데요.
    • AIMD는 세그먼트를 보내고, 그에 대한 응답이 오기까지 혼잡이 감지되지 않으면 혼잡 윈도우를 1씩 선형적으로 증가시키고, 혼잡이 감지되면 혼잡 윈도우를 절반으로 떨어뜨리는 동작을 반복하는 알고리즘을 말합니다.

TCP의 종료

➊ [송수신 방향 A → B] FIN 세그먼트
ㄴ 호스트 A는 FIN 비트가 1로 설정된 FIN 세그먼트를 호스트 B에게 전송합니다.
➋ [송수신 방향 B → A] ACK 세그먼트
ㄴ ➊에 대한 호스트 B의 응답입니다. 호스트 B는 ACK 세그먼트를 호스트 A에게 전송합니다.
➌ [송수신 방향 B → A] FIN 세그먼트
ㄴ 호스트 B는 FIN 세그먼트를 호스트 A에게 전송합니다.
➍ [송수신 방향 A → B] ACK 세그먼트
ㄴ ➌에 대한 호스트 A의 응답입니다. 호스트 A는 ACK 세그먼트를 호스트 B에게 전송합니다

 

TCP의 상태 관리

• TCP의 또 다른 중요한 특징은 상태를 유지한다는 점입니다.
• TCP는 상태를 유지하고 관리하는 프로토콜이라는 점에서 스테이트풀 프로토콜 stateful protocol 이라고도 부르는데요.
• 여기서 상태 state 란 현재 어떤 통신 과정에 있는지를 나타내는 정보를 말합니다.
  
  

5 응용 계층 - HTTP의 기초

도메인 네임과 DNS

• IP 주소로는 특정 호스트의 특징을 나타내기도 어렵고, 더욱이 호스트의 IP 주소는 언제든 바뀔 수 있기 때문입니다.
  • 그래서 사용하는 것이 도메인 네임 domain name 입니다.
    • 도메인 네임은 ‘www.example.com, developers.naver.com, git.kernel.org’와 같은 문자열 형태의 호스트 특정 정보로, 호스트의 IP 주소와 대응됩니다.

 

• 도메인 네임과 그에 대응하는 IP 주소는 네임 서버 name server 라고 불리는 특별한 서버에서 관리됩니다
• 도메인 네임을 관리하는 네임 서버는 DNS 서버 DNS server 라고도 부릅니다.

• 가령 한 호스트가 ‘minchul.net’이라는 도메인 네임을 통해 IP 주소를 알아내고자 하는 경우를 가정해 봅시다.
  • 호스트는 가장 먼저 로컬 네임 서버에게 도메인 네임을 질의하게 됩니다.
  • 로컬 네임 서버 local name server 는 클라이언트와 맞닿아 있는 네임 서버로, 클라이언트가 도메인 네임을 통해 IP 주소를 알아내고자 할 때 가장 먼저 찾게 되는 네임 서버입니다.
    
    

• 클라이언트가 로컬 네임 서버를 찾을 수 있으려면 로컬 네임 서버의 주소를 알고 있어야겠죠.
  • 그래서 많은 경우 ISP가 로컬 네임 서버의 주소를 자동으로 할당해 줍니다.
  • 다만, ISP에서 할당해 주는 로컬 네임 서버 주소가 아닌, 공개 DNS 서버 public DNS Server 를 이용할 수도 있습니다.
• 로컬 네임 서버가 FQDN에 대응하는 IP 주소를 알고 있다면 클라이언트에게 즉시 해당 IP 주소를 반환합니다.
  • 하지만 만일 로컬 네임 서버가 IP 주소를 모른다면 로컬 네임 서버는 FQDN에 대응하는 IP 주소를 알아낼 때까지 도메인 네임의 루트 도메인을 관장하는 서버(루트 네임 서버 root name server ) 에게 질의하고, 최상위 도메인을 관장하는 서버(TLD 네임 서버 TLD name server ), 그 하위 레벨의 도메인 네임을 관장하는 네임 서버, … 등에 걸쳐 질의하게 됩니다
    
    

 

DNS 레코드 유형

• A 특정 호스트에 대한 도메인 네임과 IPv4 주소와의 대응 관계
• AAAA 특정 호스트에 대한 도메인 네임과 Ipv6 주소와의 대응 관계
• CNAME 호스트 네임에 대한 별칭 지정
• NS 특정 호스트의 IP 주소를 찾을 수 있는 네임 서버
• MX 해당 도메인과 연동되어 있는 메일 서버

 

자원과 URI/URL

➊ scheme

• scheme는 자원에 접근하는 방법을 나타냅니다.
• scheme에서 명시할 수 있는 값은 매우 다양하지 만, 일반적으로는 사용할 프로토콜이 명시됩니다.
  • 가령 scheme가 ‘http://’일 경우 HTTP를 사용 하여 자원에 접근함을 나타내고, ‘https://’일 경우 HTTPS를 사용하여 자원에 접근함을 나타냅니다.

➋ authority

• authority에는 호스트를 특정할 수 있는 IP 주소나 도메인 네임이 명시됩니다. 콜론(:) 뒤에 포트 번호를 명시할 수도 있습니다.

➌ path

• path에는 자원이 위치하고 있는 경로가 명시됩니다.
  • 슬래시(/)를 기준으로 계층적으로 표현되며, 최상위 경로 또한 슬래시로 표현됩니다. 가령 ‘http 프로토콜로 접근 가능한 도메인 네임 example.com의 자원 중 /home/images/a.png에 위치한 자원’은 ‘http://example.com/home/ images/a.png’로 표현할 수 있습니다.

➍ query

• query는 URL에 대한 매개변수 역할을 하는 문자열입니다.
• 쿼리 문자열 query string , 쿼리 파라미터 queryparameter 등으로도 불립니다.

➎ fragment

• fragment는 자원의 일부분, 자원의 한 조각을 가리키기 위한 정보입니다.
  
  

 

HTTP의 특징

➊ 요청 응답 기반 프로토콜
HTTP는 기본적으로 요청 메시지를 보내는 클라이언트와 이에 대한 응답 메시지를 보내는 서버가 서로 HTTP 요청 메시지와 HTTP 응답 메시지를 주고받는 구조로 작동합니다.

➋ 미디어 독립적 프로토콜
애플리케이션의 다양한 데이터를 네트워크를 통해 송수신한다는 목적에 걸맞게 HTTP는 HTTP 메시지를 통해 HTML, JPEG, PNG, JSON, XML, PDF 등 다양한 종류의 자원을 주고받을 수 있습 니다.

➌ 스테이트리스 프로토콜

• HTTP는 상태를 유지하지 않는 스테이트리스 stateless 프로토콜입니다.
  • 즉, 서버는 HTTP 요청을 보낸 클라이언트 관련 상태를 기억하지 않습니다. 그렇기 때문에 클라이언트의 모든 HTTP 요청은 기본적으로 독립적인 요청으로 간주됩니다.
• 그렇다면 HTTP가 상태를 유지하지 않는 이유는 무엇일까요?
  • 일반적으로 HTTP 서버는 많은 클라 이언트와 동시에 상호작용합니다. 동시에 처리해야 할 요청 메시지의 수는 수천 개가 될 수도 있고, 많게는 수백만 개가 될 수도 있죠. 이런 상황에서 모든 클라이언트의 상태 정보를 유지하는 것은 서버에 큰 부담이 됩니다.
  • 또 서버는 여러 대로 구성될 수도 있는데, 여러 대로 구성된 서버 모두가 모든 클라이언트의 상태를 유지해야 한다면 어쩔 수 없이 모든 서버가 모든 클라이언트의 상태 정보를 공유해야 합니다. 하지만 이는 매우 번거롭고 복잡한 작업입니다.

➍ 지속 연결 프로토콜

• HTTP에는 버전이 있습니다. 오늘날 많이 사용되는 버전 중 하나인 HTTP 1.1과 2.0은 TCP를 기반으로 동작합니다.
• HTTP 버전(HTTP 1.1 이상)에서는 지속 연결 persistent connection 이라는 기술을 제공합니다.
  • 다른 표현으로는 킵 얼라이브 keep-alive 라고도 부르는데요. 이는 하나의 TCP 연결 상에서 여러 개의 요청-응답을 주고받을 수 있는 기술을 말합니다. 지속 연결을 통해 비지속 연결보다 빠른 속도로 여러 HTTP의 요청과 응답을 처리할 수 있습니다.

HTTP 버전별 특징

HTTP 2.0
HTTP 1.1의 단점을 보완하고 개선하기 위한 버전으로, 다음과 같은 대표적인 특징 및 추가 기능들이 있습니다.
● 바이너리 데이터 기반 송수신: 평문으로 메시지를 주고받는 HTTP 1.1과는 달리, 바이너리 데이터를 기반으로 메시지를 주고받습니다.
● 헤더 압축: 헤더를 압축하여 송수신할 수 있어 네트워크 이용 효율을 높일 수 있습니다.
● 서버 푸시(server push): 클라이언트가 요청하지 않았더라도 미래에 필요할 것으로 예상되는 자원을 미리 전송하는 기능입니다. 예를 들어 클라이언트가 ‘index.html’이라는 자원만을 요청했더라도 ‘styles.css, scripts.js’ 파일이 ‘index.html’과 함께 사용될 것으로 예상되는 경우, 이를 미리 함께 응답합니다.
● HTTP 멀티플렉싱(multiplexing) 기법: 여러 개의 독립적인 스트림(stream )을 바탕으로 요청-응답 메시지를 병렬적으로 주고받는 기술입니다. 요청과 응답을 주고받는 단위는 하나의 스트림에서 이루어 지고, 이러한 스트림 여러 개를 독립적으로 활용할 수 있는 기술입니다

HTTP 3.0
비교적 가장 최근에 등장하여 사용 비중이 점차 높아지고 있는 프로토콜입니다. HTTP 3.0의 가장 주요한 특징은 UDP를 기반으로 동작한다는 점입니다. 이전까지의 HTTP 버전들은 모두 TCP를 기반으로 동작했습 니다. 하지만 HTTP 3.0부터는 UDP, 정확하게는 UDP를 기반으로 구현된 QUIC (Quick UDP Internet Connections )이라는 프로토콜을 기반으로 동작합니다

HTTP 메시지 구조 

 

https://ebook-product.kyobobook.co.kr/dig/epd/ebook/4801169212541

이것이 취업을 위한 컴퓨터 과학이다 with CS 기술 면접 | 강민철