해당 글은 “이것이 취업을 위한 컴퓨터 과학이다.” 를 읽고 요약한 글 입니다.
자세한 내용은 책을 참고하시길 바랍니다.
이번 글에서 요약할 내용은 전송 계층 - TCP와 UDP, 응용 계층 - HTTP의 기초 및 응용, 프록시와 안정적인 트래픽에 대해서 정리해보겠습니다.
4. 전송 계층 - TCP와 UDP
전송 계층에서 가장 중요한 프로토콜은 TCP와 UDP로 각각의 목적과 특징에 대해 정리해보겠습니다.
포트를 통한 프로세스 식별
네트워크 상에서 호스트가 실행하는 프로세스는 어떻게 식별할 수 있을까요?
포트(port) 번호를 통해 식별할 수 있으며, 네트워크 패킷을 주고받는 프로세스에는 포트 번호가 할당됩니다.
IP 주소와 포트 번호의 조합(IP 주소:포트 번호)을 통해 특정 호스트가 실행하는 특정 프로세스를 식별할 수 있습니다.
포트를 통한 프로세스 식별은 전송 계층(TCP, UDP)의 주된 목적입니다.
16비트로 표현할 수 있는 포트 번호의 총 개수는 2^16인 65,536개 입니다.
포트 번호는 3가지 종류로 나뉘며, 다음과 같습니다.
- 잘 알려진 포트(well known port) : 0 ~ 1023
- 가장 대중적으로 사용되는 애플리케이션을 위한 포트 번호
- 20, 21 : FTP / 22 : SSH / 23 : TELNET / 53 : DNS
- 67, 68 : DHCP / 80 : HTTP / 443 : HTTPS
- 등록된 포트(registered port) : 1024 ~ 49151
- 잘 알려진 포트에 비해서 덜 범용적이지만 흔하게 사용되는 애플리케이션을 위한 포트 번호
- 1194 : OpenVPN / 1433 : Microsoft SQL Server 데이터베이스
- 3306 : MySQL 데이터베이스 / 6379 : Redis / 8080 : HTTP 대체
- 동적 포트(dynamic port) : 49152 ~ 65535
- 사설 포트(private port) 또는 임시 포트(ephemeral port)라고 불리기도 함
- 서버로서 동작하는 프로그램의 경우 잘 알려진 포트, 등록된 포트가 할당되는 경우가 많지만 클라이언트로서 동작하는 프로그램의 경우 동적 포트 번호 중에서 임의의 번호가 할당되는 경우가 많음
더불어 포트와 관련해서 알아야 하는 개념에는 NAT가 있습니다.
- NAT(Network Address Translation) : 공인 IP 주소와 사설 IP 주소 간 변환을 위해 사용하는 기술
- NAT는 변환하고자 하는 IP 주소를 일대일로 대응하지 않고, 다수의 사설 IP 주소를 그보다 적은 수의 공인 IP 주소로 변환함
- 이 때 활용하는 것이 바로 포트(port)임
- 포트 번호에 따라 내부 IP 주소를 구분할 수 있음
- IP 주소 변환 과정에서 변환할 IP 주소의 쌍과 더불어 포트 번호도 함께 고려하는 포트 기반의 NAT를 NAPT(Network Address Port Translation)라고 함
(비)신뢰성과 (비)연결형 보장
TCP를 통해 신뢰할 수 있는 연결형 송수신이 가능하고, UDP를 통해 신뢰할 수 없는 비연결형 송수신이 가능합니다.
차이점은 다음과 같습니다.
- TCP
- 신뢰할 수 있는 통신 - 상태 관리, 흐름 제어, 오류 제어, 혼잡 제어 제공 O
- 연결형 통신 - 연결 수립, 종료 과정이 O
- 헤더 필드 수는 UDP 보다 훨씬 많음 → UDP 헤더에 있는 모든 필드가 TCP 헤더에 포함되어 있음
- 순서 번호 필드(sequence number) : TCP 패킷의 올바른 송수신 순서를 보장하기 위해 세그먼트 첫 바이트에 매겨진 번호
- 확인 응답 번호 필드(acknowledgment number) : 상대 호스트가 보낸 세그먼트에 대한 응답으로, 다음으로 수신하길 기대하는 순서 번호
- 제어 비트 (플래그 비트) : 기본적으로 8비트로 구성되며, 각 자리에 비트가 각기 다른 의미를 가짐
- ACK : 세그먼트의 승인을 나타내기 위한 비트
- SYN : 연결을 수립하기 위한 비트
- FIN : 연결을 종료하기 위한 비트
- UDP
- 신뢰할 수 없는 통신 - 상태 관리, 흐름 제어, 오류 제어, 혼잡 제어 제공 X
- 비연결형 통신 - 연결 수립, 종료 과정이 X
- 헤더에는 포트 번호가 명시되는 필드가 있음
- 송신지 포트(Source Port) : 송신 프로세스가 할당된 포트 번호
- 수신지 포트(Destination Port) : 수신 프로세스가 할당된 포트 번호
- 길이 필드에는 헤더를 포함한 UDP 패킷의 바이트 크기가 명시
- 체크섬 필드에는 송수신 과정에서의 데이터그램 훼손 여부를 알 수 있는 정보가 명시
TCP의 연결부터 종료까지
TCP는 UDP와 달리 송수신 이전에 연결을 수립하고, 송수신 이후에는 연결을 종료합니다.
TCP는 세 단계로 이루어진 TCP의 연결 수립 과정인 쓰리 웨이 핸드셰이크(three-way handshake)를 통해 이루어집니다.
각각의 단계는 다음과 같습니다.
- [송수신 방향 A → B] SYN 세그먼트 전송
- 호스트 A는 SYN 비트가 1로 설정된 세그먼트를 B에게 전송함
- SYN 비트는 연결을 수립하기 위한 비트임
- 세그먼트의 순서 번호에는 호스트 A의 순서 번호가 포함됨
- 처음 연결을 시작하는 이 과정을 액티브 오픈(active open) 이라고 함
- 주로 클라이언트에 의해 수행됨
- 호스트 A는 SYN 비트가 1로 설정된 세그먼트를 B에게 전송함
- [송수신 방향 B → A] SYN + ACK 세그먼트 전송
- 위 전송에 대한 호스트 B의 응답을 의미
- B는 ACK 비트와 SYN 비트가 1로 설정된 세그먼트를 A에게 전송함
- 세그먼트의 순서 번호에는 호스트 B의 순서 번호와 위에서 보낸 세그먼트에 대한 확인 응답 번호가 포함됨
- 연결 요청을 수신한 뒤 그에 대한 연결을 수립하는 이 과정을 패시브 오픈(passive opne)이라고 함
- 주로 서버에 의해 수행됨
- [송수신 방향 A → B] ACK 세그먼트 전송
- 호스트 A는 ACK 비트가 1로 설정된 세그먼트를 B에게 전송함
- 세그먼트의 순서 번호에는 호스트 A의 순서 번호와 위에서 보낸 세그먼트에 대한 확인 응답 번호가 포함됨
TCP는 송수신하는 패킷의 신뢰성을 보장하기 위해 크게 3가지 기능을 제공합니다.
각각의 기능에 대한 설명은 다음과 같습니다.
- 재전송을 통한 오류 제어
- 송수신 과정에서 잘못 전송된 세그먼트가 있을 경우, 재전송하여 오류를 제어함
- 중복된 ACK 세그먼트가 도착했을 때 잘못 전송된 세그먼트가 있다는 것을 인지하는 경우
- 송신한 세크먼트의 일부가 전송 중 유실되어 중복으로 ACK 세그먼트를 수신하게 되는 상황
- 타임아웃이 발생했을 때 잘못 전송된 세그먼트가 있다는 것을 인지하는 경우
- 송신하는 호스트는 모두 재전송 타이머라는 값을 유지하는데, 이 타이머의 카운트다운이 끝난 상황을 타임아웃이라고 함
- 흐름 제어
- 수신 호스트가 한 번에 받아 처리할 수 있을 만큼만 전송하는 것을 의미
- 송신 호스트가 수신 호스트의 처리 속도를 고려하며 송수신 속도를 균일하게 맞추는 기능임
- 수신 호스트가 한 번에 받을 수 있는 전송량은 TCP 수신 버퍼의 크기에 의해 결정됨 - 커널에 정의되어 있음
- TCP 헤더에 있는 윈도우(window) 필드를 통해 한 번에 처리할 수 있는 양을 알 수 있음
- 윈도우 필드에는 수신 호스트가 한 번에 처리할 수 있는 수신 윈도우 크기가 명시됨
- 혼잡 제어
- 많은 트래픽으로 인해 패킷의 처리 속도가 느려지거나 유실될 수 있는 상황을 제어하기 위한 기능
- 송신 호스트가 주체적으로 네트워크가 얼마나 혼잡한지 판단하고, 전송량을 조절할 수 있어야 함
- 송신 호스트는 중복된 ACK 세그먼트가 도착했을 때, 타임아웃이 발생했을 때 혼잡할 수 있다고 판단함
- 혼잡 없이 전송할 수 있을 정도의 양만큼만 송신함
- 해당 값을 혼잡 윈도우라고 함
- 혼잡 윈도우가 크면 한 번에 전송할 수 있는 세그먼트의 수가 많음을 의미함
- 혼잡 윈도우의 크기를 송신 호스트가 직접 계산해서 알아내야 되는데, 이 때 크기 연산하는 방법을 혼잡 제어 알고리즘(congestion control algorithm)이라고 함
- 대표적으로 AIMD(Additive Increase/Multiplicative Decrease)가 있음
- 세그먼트를 보내고, 그에 대한 응답이 오기까지 혼잡이 감지되지 않으면 혼잡 윈도우를 1씩 선형적으로 증가시키고, 감지되면 혼잡 윈도우를 절반으로 떨어뜨리는 동작을 반복하는 알고리즘
- 패킷을 보내고 그에 대한 응답이 수신되기까지의 시간을 RTT(Round Trip Time)라고 함 → RTT마다 증가하는 것임
TCP의 연결 종료는 송수신 호스트가 각자 한 번씩 FIN과 ACK를 주고 받으며 이루어집니다.
다음과 같은 단계를 거쳐 종료됩니다.
- [송수신 방향 A → B] FIN 세그먼트
- 호스트 A는 FIN 비트가 1로 설정된 세그먼트를 호스트 B에게 전송함
- 먼저 연결을 종료하려는 호스트에 의해 수행되는 동작을 액티브 클로즈(active close)라고 함
- [송수신 방향 B → A] ACK 세그먼트
- 위 전송에 대한 호스트 B의 응답을 의미
- 호스트 B는 ACK 세그먼트를 A에게 전송함
- [송수신 방향 B → A] FIN 세그먼트
- 호스트 B는 FIN 세그먼트를 A에게 전송함
- 연결 종료 요청을 받아들이는 호스트에 의해 수행되는 동작을 패시브 클로즈(passive close)라고 함
- [송수신 방향 A → B] ACK 세그먼트
- 위 전송에 대한 호스트 A의 응답을 의미
- 호스트 A는 ACK 세그먼트를 B에게 전송함
TCP의 상태 관리
TCP는 상태를 유지하고 관리하는 프로토콜이라는 점에서 스테이트풀 프로토콜(stateful protocol)이라고 부릅니다.
여기에서 상태는 현재 어떤 통신 과정에 있는지를 나타내는 정보를 의미하며, 여러 상태에 대한 설명은 다음과 같습니다.
- 연결이 수립되지 않았을 때 주로 활용되는 상태
- CLOSED : 아무런 연결이 없는 상태
- LISTEN : 연결 대기 상태(쓰리 웨이 핸드셰이크의 첫 단계인 SYN 세그먼트를 대기하는 상태)
- 연결 수립 과정에서 주로 활용되는 상태
- SYN-SENT : 액티브 오픈 호스트가 SYN 세그먼트를 보낸 뒤, 응답인 SYN + ACK 세그먼트를 기다리는 상태 (연결 요청 전송)
- SYN-RECEIVED : 패시브 오픈 호스트가 SYN + ACK 세그먼트를 보낸 뒤, 응답인 ACK 세그먼트를 기다리는 상태 (연결 요청 수신)
- ESTABLISHED : 쓰리 웨이 핸드셰이크가 끝난 뒤 데이터를 송수신할 수 있는 상태 (연결 수립)
- 연결 종료 과정에서 주로 활용되는 상태
- FIN-WAIT-1 : 액티브 클로즈 호스트가 FIN 세그먼트로 연결 종료 요청을 보낸 상태 (연결 종료 요청 전송)
- CLOSE-WAIT : FIN 세그먼트를 받은 패시브 클로즈 호스트가 응답으로 ACK 세그먼트를 보내고 대기하는 상태 (연결 종료 요청 승인)
- FIN-WAIT-2 : FIN-WAIT-1 상태에서 ACK 세그먼트를 받은 상태
- LAST-ACK : CLOSE-WAIT 상태에서 FIN 세그먼트를 전송한 뒤 대기하는 상태
- TIME-WAIT : 액티브 클로즈 호스트가 마지막 ACK 세그먼트를 전송한 뒤 접어드는 상태
5. 응용 계층 - HTTP의 기초
도메인 네임과 DNS
네트워크 상의 호스트를 식별하기 위해 기본적으로 사용되는 정보는 IP 주소입니다.
IP 주소로는 특정 호스트의 특징을 나타내기도 어렵고, 호스트의 IP 주소는 언제든 바뀔 수 있기에 도메인 네임(domain name)입니다.
도메인 네임과 그에 대응하는 IP 주소는 네임 서버(name server)라고 불리는 특별한 서버에서 관리됩니다.
도메인 네임을 관리하는 네임 서버는 DNS 서버(DNS server)라고도 부릅니다.
호스트는 네임 서버에 특정 도메인 네임을 가진 호스트의 IP 주소가 무엇인지 질의함으로써 패킷을 주고받고자 하는 호스트의 IP 주소를 얻어낼 수 있습니다.
IP 주소를 모르는 상태에서 도메인 네임에 대응되는 IP 주소를 알아내는 과정을 두고 리졸빙(resolve + ing)한다고 표현합니다.
도메인 네임과 관련해 알아야 할 내용으로는 2가지로 도메인 네임의 계층적 구조이고, 다른 하나는 도메인 네임을 관리하는 네임 서버의 계층적 구조입니다.
하나의 도메인 네임은 점(.)을 기준으로 계층적으로 분류되어 있으며, 구조는 다음과 같습니다.
최상단에 루트 도메인, 최상위 도메인(TLD), 2단계 도메인(세컨드 레벨 도메인), 3단계 도메인으로 이루어져 있습니다.
도메인의 단계는 늘어날 수 있지만 일반적으로 3~5단계 정도로 구성됩니다.
도메인 네임을 모두 포함하는 도메인 네임은 전체 주소 도메인 네임(FQDN : Fully-Qualified Domain Name)이라고 하며, 이를 알면 호스트를 식별할 수 있습니다.
이렇게 계층적인 형태로 이루어진 도메인 네임을 관리하는 네임 서버 또한 계층적 형태를 이룹니다.
네임 서버는 분산되어 관리되는데, 계층적으로 분산되어 있는 도메인 네임에 대한 관리 체계는 도메인 네임 시스템(DNS)라고 부릅니다.
도메인 네임이 계층적으로 분산되어 있는 네임 서버를 바탕으로 리졸빙 되는 과정은 다음과 같습니다.
- 클라이언트가 IP 주소를 알아내고자 할 때 가장 먼저 로컬 네임 서버에게 도메인 네임을 질의함
- 로컬 네임 서버(local name server) : 클라이언트와 맞닿아 있는 네임 서버
- 로컬 네임 서버 주소의 경우 ISP가 로컬 네임 서버의 주소를 자동으로 할당해줌
- 할당해주는 로컬 네임 서버 주소 뿐만 아니라 공개 DNS 서버를 이용할 수도 있음
- 로컬 네임 서버가 FQDN에 대응하는 IP 주소를 알고 있을 경우 클라이언트에게 해당 IP 주소를 반환함
- 로컬 네임 서버가 IP 주소를 모를 경우에는
- 도메인 네임의 루트 도메인을 관장하는 서버(루트 네임 서버)에게 질의
- 최상위 도메인을 관장하는 서버(TLD 네임 서버)
- 하위 레벨의 도메인 네임을 관장하는 네임 서버 등에 걸쳐 질의를 하게 됨
- 클라이언트가 원하는 IP 주소를 반환 받으면 클라이언트에게 전달함
위와 같은 질의 과정이 많이 반복되면 오랜 시간이 걸리기에 실제로는 네임 서버들이 기존에 응답받은 결과를 임시로 저장했다가 같은 질의에 활용하는 경우가 많습니다.
이를 DNS 캐시라고 하며, 자주 질의되는 도메인 네임인 경우 대부분이 로컬 네임 서버 선에서 캐시되어 있습니다.
자원과 URI/URL
웹 상에서의 자원과 URI에 대해 알아보겠습니다.
네트워크의 맥락에서 사용되는 자원(resource)의 의미는 네트워크 상의 메시지를 통해 주고받는 최종 대상을 뜻합니다.
URI(Uniform Resource Identifier)는 웹 상에서의 자원을 식별하기 위한 정보를 의미합니다.
자원을 어떤 것으로 식별하는 지에 따라 나뉩니다.
- 이름을 기반으로 식별 → URN(Uniform Resource Name)
- 위치를 기반으로 식별 → URL(Uniform Resource Locator)
자원 식별에 더 많이 사용되는 방법은 URL로, URL 구조에 대해 알아보겠습니다.
- scheme : 자원에 접근하는 방법
- 일반적으로 사용할 프로토콜이 명시됨 - http, https
- authority : 호스트를 특정할 수 있는 IP 주소나 도메인 네임
- 콜론(:) 뒤에 포트 번호를 명시할 수 있음
- path : 자원이 위치하고 있는 경로
- 슬래시(/)를 기준으로 계층적으로 표현됨
- query : URL에 대한 매개변수 역할을 하는 문자열
- 쿼리 문자열(query string), 쿼리 파라미터(query parameter)로 불림
- 물음표로 시작되는 <키=값> 형태의 데이터로, &를 사용하여 여러 쿼리 문자열을 연결할 수 있음
- fragment : 자원의 일부분, 자원의 한 조각을 가리키기 위한 정보
- 일반적으로 HTML 파일과 같은 자원에서 특정 부분을 가리키는 데 사용됨
HTTP의 특징
HTTP의 주 목적은 데이터의 형식에 구애받지 않고, 다양한 애플리케이션 데이터의 송수신을 가능하게 하는 것 입니다.
HTTP에는 주요 특징 4가지는 다음과 같습니다.
- 요청 응답 기반 프로토콜
- 요청 메시지를 보내는 클라이언트, 응답 메시지를 보내는 서버가 서로 HTTP 메시지를 주고받는 구조로 작동함
- 미디어 독립적 프로토콜
- HTTP 메시지를 통해 다양한 종류의 자원을 주고받을 수 있음
- HTTP에서 메시지로 주고받는 자원의 종류는 미디어 타입이라고 함
- 기본적으로 슬래시를 기준으로 타입/서브타입의 형식으로 구성됨
- 타입에는 text, image, video, audio, application, multipart가 있음
- 스테이트리스 프로토콜
- 서버는 HTTP 요청을 보낸 클라이언트 관련 상태를 기억하지 않음
- 상태를 유지하지 않는 이유는 HTTP 서버는 많은 클라이언트와 동시에 상호작용하기 때문 → 서버에 부담
- 지속 연결 프로토콜
- 대중적으로 사용되고 있는 HTTP 지속 연결(persistent connection)이라는 기술 제공함
- 다른 표현으로 keep-alive라고 부름
- 하나의 TCP 연결 상에서 여러 개의 요청-응답을 주고받을 수 있는 기술을 뜻함
HTTP 메시지 구조
HTTP 메시지는 기본적으로 시작 라인, 필드 라인, 메시지 본문으로 이루어져 있습니다.
HTTP는 요청 응답 기반의 프로토콜로, HTTP 요청 메시지와 HTTP 응답 메시지가 있습니다.
메시지 구조는 다음과 같습니다.
- 시작 라인(start-line) : 요청 메시지인지 응답 메시지인지 구분할 수 있음
- 요청 라인(request-line) : 메서드(method), 요청 대상, HTTP 버전으로 구성
- 상태 라인(status-line) : HTTP 버전, 상태 코드(status code), 이유 구문(reason phrase)으로 구성
- 필드 라인(field-line) : HTTP 헤더가 명시됨
- HTTP 헤더는 메시지 전송과 관련된 부가 정보이며, 제어 정보임
- 콜론(:)을 기준으로 헤더 이름, 헤더 값으로 구성
- 메시지 본문
HTTP 메서드와 상태 코드
| HTTP 메서드 | 설명 |
|---|---|
| GET, HEAD | 웹 브라우저를 통해 웹 사이트의 자원을 조회하는 용도의 메서드 GET에는 응답 메시지에 메시지 본문이 포함되어 있으나, HEAD에는 포함되지 않음 |
| POST | 서버로 하여금 특정 작업을 처리하도록 요청하는 용도로 사용되는 메서드 주로 클라이언트가 서버에 새로운 자원을 생성하고자 할 때 사용됨 |
| PUT, PATCH | PUT의 경우에는 덮어쓰기를 요청하고, PATCH의 경우에는 부분적 수정을 요청함 |
| DELETE | 특정 자원의 삭제를 요청할 때 사용되는 메서드 |
| 상태 코드 범위 | 상태 코드 | 설명 |
|---|---|---|
| 200번대 : 성공 | 200 - OK | 요청 성공 |
| 201 - Created | 요청 성공, 새로운 자원이 생성됨 | |
| 202 - Accepted | 요청을 잘 받았으나, 아직 요청 작업이 끝나지 않음 | |
| 203 - No Content | 요청이 성공했지만 메시지 본문 데이터가 없음 | |
| 300번대 : 리다이렉션 | 301 - Moved Permanently | 영구적 리다이렉션 / 재요청 메서드가 변경될 수 있음 |
| 308 - Permanent Redirect | 영구적 리다이렉션 / 재요청 메서드가 변경되지 않음 | |
| 302 - Found | 일시적 리다이렉션 / 재요청 메서드가 변경될 수 있음 | |
| 303 - See Other | 일시적 리다이렉션 / 재요청 메서드가 GET으로 변경됨 | |
| 307 - Temporary Redirect | 일시적 리다이렉션 / 재요청 메서드가 변경되지 않음 | |
| 304 - Not Modified | 캐시 / 자원이 변경되지 않음 | |
| 400번대 : 클라이언트 에러 | 400 - Bad Request | 요청 메시지의 내용이나 형식 자체에 문제가 있음 |
| 401 - Unauthorized | 요청한 자원에 대한 유효한 인증이 없음 | |
| 403 - Forbidden | 요청이 서버에 의해 거부됨 (자원에 대한 접근 권한 충분하지 X) |
|
| 404 - Not Found | 요청 받은 자원을 찾을 수 없음 | |
| 405 - Method Not Allowed | 요청한 메서드를 지원하지 않음 | |
| 500번대 : 서버 에러 | 500 - Internal Server Error | 요청을 처리할 수 없음 |
| 502 - Bad Gateway | 중간 서버의 통신 오류 |
/
HTTP 주요 헤더
HTTP 헤더의 종류는 다양하나 빈번하게 사용되는 헤더들에 대해서 정리하겠습니다.
- 요청 메시지에서 주로 활용되는 HTTP 헤더
- Host : 요청을 보낼 호스트가 명시되는 헤더
- 도메인 네임이나 IP 주소로 표현되며, 포트 번호가 포함될 수 있음
- User-Agent : 요청 메시지를 보낸 클라이언트의 프로그램과 관련한 정보가 명시됨
- 브라우저의 종류, 운영체제 및 아키텍처의 정보, 웹 브라우저에 시각적 요소를 구현하는 렌더링 엔진 종류 등이 있음
- Referer : 클라이언트가 요청을 보낼 때 머무르던 URL이 명시됨
- 이를 통해 클라이언트의 유입 경로를 파악할 수 있음
- Host : 요청을 보낼 호스트가 명시되는 헤더
- 응답 메시지에서 주로 활용되는 HTTP 헤더
- Server : 응답 메시지를 보내는 서버 호스트와 관련된 정보가 명시됨
- Allow : 처리 가능한 HTTP 헤더 목록을 알리기 위해 사용
- Location : 클라이언트에게 자원의 위치를 알려 주기 위해 사용
- 요청, 응답 메시지 모두에서 활용되는 HTTP 헤더
- Date : 메시지가 생성된 날짜와 시각에 관련된 정보
- Content-Length : 메시지 본문의 바이트 단위 크기를 표현하기 위해 사용
- Content-Type, Content-Language, Content-Encoding : 메시지 본문이 어떻게 표현되었는지와 관련된 헤더 → 표현 헤더라고 부르기도 함
- Connection : HTTP 메시지를 송신하는 호스트가 어떠한 방식의 연결을 원하는지 명시하는 헤더
6. 응용 계층 - HTTP의 응용
쿠키
HTTP의 스테이트리스한 특성을 보완하기 위한 대표적 수단 입니다.
서버에서 생성되어 클라이언트 측에 저장되는 <이름, 값> 쌍 형태의 데이터 입니다.
쿠키의 만료 기간과 같은 추가적인 속성값도 가질 수 있으며, 클라이언트는 주로 브라우저에 쿠키를 저장합니다.
서버가 클라이언트에게 쿠키를 전송할 때는 Set-Cookie 헤더가 활용되고, 클라이언트에서 쿠키를 저장해두었다가 서버에게 쿠키를 건넬 때는 Cookie 헤더가 활용됩니다.
쿠키의 대표적인 속성은 다음과 같습니다.
- domain, path : 쿠키를 전송할 도메인과 경로를 제한할 수 있음
- Expires : 요일, DD-MM-YY HH:MM:SS GMT의 형식으로 표시되는 쿠키 만료 시점
- Max-Age : 초 단위 유효기간을 의미
- Secure : HTTPS를 통해서만 쿠키를 송수신하도록 함
- HttpOnly : 자바스크립트를 통한 쿠키의 접근 제한, HTTP 송수신을 통해서만 쿠키에 접근하도록 함
캐시
HTTP에서 캐시는 응답 받은 자원의 사본을 임시 저장하여 불필요한 대역폭 낭비와 응답 지연을 방지하는 기술입니다.
이로 인해 동일한 요청 메시지를 보내야 할 때 임시 저장된 사본을 재활용할 수 있으며, 더 빠르게 자원에 접근할 수 있습니다.
대부분 유효기간이 설정되어 있는데, 이는 원본 데이터와 캐시된 사본 데이터 간의 일관성이 깨질 수 있기 때문입니다.
캐시의 유효기간을 설정하고 만료된 자원을 재요청함으로써 캐시 신선도를 검사할 수 있고, 원본 데이터가 변경되었을 때 해당 자원을 다시 응답 받음으로써 캐시 신선도를 높게 유지할 수 있습니다.
- 캐시 신선도 : 캐시된 사본 데이터가 서버의 원본 데이터와 얼마나 유사한지의 정도
원본 데이터가 항상 변경되는 건 아니기 때문에 클라이언트는 캐시된 자원의 유효기간이 만료되었을 때 서버에게 원본 자원이 변경된 적이 있는지 질의합니다.
변경 여부를 물어볼 때는 날짜 또는 엔티티 태그를 기반으로 물어볼 수 있습니다.
- 엔티티 태그(Etag) : 자원의 버전을 식별하기 위한 정보
- 날짜 기반으로 변경 여부를 물을 때는 If-Modified-Since 헤더가 대표적임
- 엔티티 태그 기반으로 변경 여부를 물을 때는 If-None-Match 헤더를 사용함
콘텐츠 협상
서버와 클라이언트가 HTTP 메시지를 통해 주고 받는 것은 자원의 표현이라고 합니다.
- 표현(representation) : 송수신 가능한 자원의 형태를 의미
같은 자원에 대해 할 수 있는 여러 표현 중 클라이언트가 가장 적합한 자원의 표현을 제공하는 기술을 콘텐츠 협상(content negotiation)이라고 합니다.
대표적인 콘텐츠 협상 헤더는 다음과 같습니다.
- Accept : 선호하는 미디어 타입을 나타내는 헤더
- Accept-Language : 선호하는 언어를 나타내는 헤더
- Accept-Encoding : 선호하는 인코딩 방식을 나타내는 헤더
보안: SSL/TLS와 HTTPS
많은 웹 서비스는 HTTP에 안전성을 더한 프로토콜인 HTTPS(HTTP over TLS, HTTP Secure)로 동작합니다.
- HTTPS : HTTP에 SSL 혹은 TLS라는 프로토콜의 동작이 추가된 프로토콜
- SSL, TLS : 인증과 암호화를 수행하는 프로토콜로, TLS는 SSL를 계승한 프로토콜
오늘날 주로 사용되는 버전은 상대적으로 최근에 출시된 TLS 1.3의 비중이 커지고 있습니다.
TLS 1.3 기반 HTTPS 메시지는 다음과 같은 단계를 거쳐 송수신됩니다.
- TCP 쓰리 웨이 핸드셰이크
- TLS 핸드셰이크
- 암호화 통신을 위한 키를 생성/교환할 수 있음
- TLS 핸드셰이크 과정에서 ClientHello, ServerHello 메시지를 주고받으며 생성/교환됨
- 인증서 송수신과 검증이 이루어질 수 있음
- 인증 기관(CA)에서 인증서를 발급, 검증, 저장 등의 역할을 수행함
- 암호화 통신을 위한 키를 생성/교환할 수 있음
- 메시지 송수신
7. 프록시와 안정적인 트래픽
오리진 서버와 중간 서버: 포워드 프록시와 리버스 프록시
클라이언트와 서버 사이에는 수많은 네트워크 장비들이 있을 수 있고, 서버를 보완하는 수많은 중간 서버들도 있을 수 있습니다.
많은 네트워크 장비와 서버들 사이에서 클라이언트가 최종적으로 메시지를 주고받는 대상인 자원을 생성하고, 클라이언트에게 권한이 있는 응답을 보낼 수 있는 HTTP 서버를 오리진 서버(origin server)라고 합니다. (클라이언트 - 중간 서버 - 오리진 서버)
대표적인 중간 서버의 유형에는 프록시, 게이트웨이가 있습니다.
- 프록시(proxy) : 클라이언트가 선택한 메시지 전달의 대리자
- 주로 캐시 저장, 클라이언트 암호화 및 접근 제한 등의 기능을 제공함
- 게이트웨이(gateway) : 오리진 서버들을 향하는 요청 메시지를 먼저 받아서 오리진 서버들에게 전달하는 문지기, 경비 역할을 수행
- 캐시 저장, 부하를 분산하는 로드 밸런서로도 동작할 수 있음
고가용성: 로드밸런싱과 스케일링
가용성은 주어진 특정 기능을 실제로 수행할 수 있는 시간의 비율을 의미합니다.
수식으로는 업타임 / (업타임 + 다운타임) 로 표현할 수 있습니다.
- 업타임(uptime) : 정상적인 사용 시간을 의미
- 다운타임(downtime) : 모종의 이유로 인해 정상적인 사용이 불가능한 시간을 의미
고가용성은 위 수식의 값이 높은 성질을 의미하기에, 전체 사용 시간 중 대부분을 사용할 수 있는 특성을 뜻합니다.
안정적이라고 평가받는 시스템의 가용성에 대한 백분율 값은 99.999% 이상을 목표로 하지만 다운타임의 발생 원인은 다양합니다.
고가용성을 유지하는 것의 핵심은 문제가 발생하더라도 계속 기능할 수 있도록 설계하는 것에 가깝습니다.
이런 능력을 결함 감내(fault tolerance)라고 합니다.
대표적인 기술로는 서버를 다중화하여 다른 예비 서버가 대신해 동작할 수 있도록 하는 것입니다.
고가용성이 필요한 호스트는 서버로, 서버를 다중화했다고 해도 반드시 고가용성이 보장되지는 않습니다.
특정 서버에만 트래픽이 몰린다면 가용성은 떨어질 수 있습니다.
트래픽의 고른 분배를 위해 사용되는 기술이 바로 로드 밸런싱(load balancing)입니다.
로드 밸런서(load balancer)에 의해 수행되는데, 다중화된 서버와 클라이언트 사이에 위치하며 클라이언트의 요청들을 각 서버에 균등하게 분배하는 역할을 합니다.
이 때 부하가 균등하게 분산되도록 요청을 전달할 서버를 선택하는 방법을 로드 밸런싱 알고리즘이라고 합니다.
대표적인 알고리즘은 다음과 같습니다.
- 라운드 로빈 알고리즘(round robin algorithm) : 단순히 서버를 돌아가며 부하를 전달
- 최소 연결 알고리즘(least connection algorithm) : 연결이 적은 서버부터 우선적으로 부하를 전달
성능이 뛰어난 장비를 사용하면 그렇지 않은 장비를 사용할 때보다는 가용성이 높아지는 것은 사실이지만 그것이 정답은 아닙니다.
이와 관련된 2가지의 방법은 다음과 같습니다.
- 스케일 업 (수직적 확장) : 기존 서버를 더 나은 사양으로 교체하는 방법
- 설치와 구성이 단순함
- 스케일 아웃에 비해 유연하지는 않음
- 스케일 아웃 (수평적 확장) : 기존 서버를 여러 개로 두는 방법
- 유연한 확장 및 축소 가능
- 스케일 업으로 확장했을 때 보다 결함을 감내하기가 더 용이함
마치며
새로 알게 된 점
서버와 관련된 부분에 대해서 많은 것을 이해하게 되는 계기가 되었습니다.
특히 최근에 구현했던 부분은 위의 챕터에 대한 이해가 필요했던 부분이었던 것 같습니다.
Quiz
1. TCP의 연결 수립 과정에서 사용되는 절차인 "쓰리 웨이 핸드셰이크"와 관련이 없는 항목은?
A. SYN
B. FIN
C. ACK
D. 순서 번호
2. 도메인 네임을 기반으로 IP 주소를 알아내는 과정은 무엇인가요?
3. HTTP 캐시와 관련된 개념 중 캐시된 데이터가 서버의 원본 데이터와 얼마나 일치하는지를 나타내는 용어는?
A. 캐시 신선도
B. 캐시 유효성
C. 캐시 만료
D. 캐시 일관성
4. 다음 중 스케일링 방식 중 기존 서버의 사양을 높여 성능을 향상시키는 방법은?
A. 스케일 인
B. 스케일 아웃
C. 스케일 다운
D. 스케일 업
정답
1번 : B. FIN
2번 : 리졸빙 (Resolving)
3번 : A. 캐시 신선도
4번 : D. 스케일 업