Chapter1. TCP/IP
패킷교환 방식의 이점에 대해 이해한다.
IP의 비순서성, 비신뢰성에 대해 이해한다.
TCP의 3 way handshake 및 그와 비교되는 UDP에 대해 이해한다.
Chapter1-1. 네트워크의 시작
인터넷이 대중화되면서 네트워크는 컴퓨터 기술에서 빼놓을 수 없는 분야가 됨.
이러한 네트워크는 어디서부터 시작된 걸까?
지금 우리가 사용하는 인터넷 프로토콜, 즉 IP 기반의 네트워크는 미 국방성에서 1969년 진행했던 아르파넷(ARPANET) 프로젝트에서 시작됨
이 프로젝트는 당시 냉전시대에서 핵전쟁을 대비하기 위한 통신망 구축을 위해 추진되었음
이때 기존에 사용되었던 회선교환 방식이 아닌 패킷교환 방식으로 네트워크를 구축하게 되는데 이를 토대로 현재의 인터넷 통신 방식의 기반이 세워짐
회선교환 방식
회선교환 방식은 발신자와 수신자 사이에 데이터를 전송할 전용선을 미리 할당하고 둘을 연결한다(우리가 전화하는 방식)
그래서 내가 연결하고 싶은 상대가 다른 상대와 연결중이라면, 상대방은 이미 다른 상대와의 전용선과 연결되어 있기 때문에 그 연결이 끊어지고 나서야 상대방과 연결할 수 있음
특정 회선이 끊어지는 경우에는 처음부터 다시 연결을 성립해야 함
회선교환 방식은 즉시성이 떨어진다는 비효율이 존재
패킷교환 방식
패킷교환 방식은 기존에 전화에서 사용했던 회선교환 방식의 단점을 보완한 방식으로 패킷이라는 단위로 데이터를 잘게 나누어 전송하는 방식
소포를 보내듯 각 패킷에는 출발지와 목적지 정보가 있고 이에 따라 패킷이 목적지를 향해 가장 효율적인 방식으로 이동할 수 있음
이를 이용하면 특정 회선이 전용선으로 할당되지 않기 때문에 빠르고 효율적으로 데이터를 전송할 수 있음
정리하면 인터넷 프로토콜, 줄여서 IP는 출발지와 목적지의 정보를 IP 주소라는 특정한 숫자값으로 표기하고 패킷단위로 데이터를 전송하게 됨
Chapter1-2. IP/IP Packet
복잡한 인터넷 망 속 수많은 노드들을 지나 어떻게 클라이언트와 서버가 통신할 수 있을까?
(여기서 노드는 하나의 서버 컴퓨터를 의미)
출발지에서 목적지까지 데이터가 무사히 전달되기 위해선 규칙이 필요할 것임
그래서 흔히 말하는 IP(인터넷 프로토콜) 주소를 컴퓨터에 부여하여 이를 이용해 통신함.
IP는 지정한 IP 주소(IP Address)에 패킷(Packet)이라는 통신 단위로 데이터를 전달함
IP 패킷 정보
IP 패킷에서 패킷은 pack과 bucket이 합쳐진 단어로 소포로 비유할 수 있음
IP 패킷은 우체국 송장처럼 전송 데이터를 무사히 전송하기 위해 출발지 IP, 목적지 IP와 같은 정보가 포함되어 있음
클라이언트 패킷 전달 - 서버 패킷 전달
패킷 단위로 전송을 하면 노드들은 목적지 IP에 도달하기 위해 서로 데이터를 전달함
서버에서 무사히 데이터를 전송받는다면 서버도 이에 대한 응답을 돌려줘야 함.
서버 역시 IP 패킷을 이용해 클라이언트에 응답을 전달한다.
IP 프로토콜의 한계
비연결성
패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
클라이언트는 서버의 상태를 파악할 방법이 없기 때문에 패킷을 그대로 전송하게 됨
비신뢰성
중간에 패킷이 사라질 수 있음
중간에 있는 서버가 데이터를 전달하던 중 장애가 생겨 패킷이 중간에 소실되더라도 클라이언트는 이를 파악할 방법이 없음
패킷의 순서를 보장할 수 없음
전달 데이터의 용량이 클 경우 이를 패킷 단위로 나눠 데이터를 전달하게 되는데 이때 패킷들은 중간에 서로 다른 노드를 통해 전달될 수 있음. 이렇게 되면 클라이언트가 의도하지 않은 순서로 서버에 패킷이 도착할 수 있음
Chapter1-3. TCP/UDP Packet
네트워크 계층 구조를 통해 위에서 알아본 IP 패킷의 한계를 어떻게 보완할 수 있을지 알아보자
OSI 7계층과 TCP/IP 4 계층
네트워크 프로토콜 계층은 다음과 같이 OSI 7계층과 TCP/IP 4 계층으로 나눌 수 있음
IP 프로토콜 보다 더 높은 계층에 TCP 프로토콜이 존재하기 때문에 앞서 다룬 IP 프로토콜의 한계를 보완할 수 있음
💡 TCP/IP 4 계층은 OSI 7 계층보다 먼저 개발되었으며 TCP/IP 프로토콜의 계층은 OSI 모델의 계층과 정확하게 일치하지는 않음. 실제 네트워크 표준은 업계표준을 따르는 TCP/IP 4 계층에 가깝다
예시) 채팅프로그램에서 메시지를 보낼때 어떤일이 일어날까?
채팅창에서 'Hello, World!'메시지 생성
HTTP 메시지가 생성되면 Socket을 통해 전달됨
💡 프로그램이 네트워크에서 데이터를 송수신할 수 있도록, “네트워크 환경에 연결할 수 있게 만들어진 연결부“가 바로 네트워크 소켓(Socket)
TCP 세그먼트 생성, 메시지 데이터 포함
IP 패킷 생성, TCP 데이터 포함
생성된 TCP/IP 패킷은 LAN 카드와 같은 물리적 계층을 지나기 위해 이더넷 프레임 워크에 포함되어 서버로 전송됨
TCP/IP 패킷
TCP 세그먼트에는 IP 패킷의 출발지 IP와 목적지 IP 정보를 보완할 수 있는 출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보 등을 포함함.
TCP 특징
전송제어 프로토콜(Transmission Control Protocol).
TCP는 같은 계층에 속한 UDP에 비해 상대적으로 신뢰할 수 있는 프로토콜
연결 지향 - TCP 3 way handshake(가상 연결)
데이터 전달 보증
순서 보장
신뢰할 수 있는 프로토콜
연결 지향 - TCP 3 way handshake(가상 연결)
TCP는 장치들 사이에 논리적인 접속을 성립하기 위하여 3 way handshake를 사용하는 연결지향형 프로토콜
클라이언트는 서버에 접속을 요청하는 SYN 패킷을 보냄
서버는 SYN요청을 받고 클라이언트에게 요청을 수락한다는 ACK 와 SYN가 설정된 패킷을 발송하고 클라이언트가 다시 ACK으로 응답하기를 기다림
클라이언트가 서버에게 ACK을 보냄
- 이 이후로부터 연결이 성립되며 데이터를 전송할 수 있음
- 만약 서버가 꺼져있다면 클라이언트가 SYN을 보내고 서버에서 응답이 없기 때문에 데이터를 보내지 않음
- 현재에는 최적화가 이루어져 3번 ACK을 보낼때 데이터를 함께 보내기도 함
💡 SYN은 Synchronize, ACK는 Acknowledgment의 약자
데이터 전달 보증
TCP는 데이터 전송이 성공적으로 이루어진다면 이에 대한 응답을 돌려주기 때문에 IP 패킷의 한계인 비연결성을 보완할 수 있음
순서 보장
만약 패킷이 순서대로 도착하지 않는다면 TCP 세그먼트에 있는 정보를 토대로 다시 패킷 전송을 요청할 수 있음
이를 통해 IP 패킷의 한계인 비신뢰성(순서를 보장하지 않음)을 보완할 수 있음.
UDP 특징
사용자 데이터그램 프로토콜 (User Datagram Protocol)
UDP는 IP 프로토콜에 PORT, 체크섬 필드 정보만 추가된 단순한 프로토콜
하얀 도화지에 비유됨(기능이 거의 없음)
HTTP3는 UDP를 사용하며 이미 여러 기능이 구현된 TCP보다는 하얀 도화지처럼 커스터마이징이 가능하다는 장점이 있음
비연결지향 - TCP 3 way handshake x
3 way handshake 방식을 사용하지 않기 때문에 TCP와 비교해 빠른 속도를 보장
데이터 전달 보증 x
순서 보장 x
데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름
신뢰성 보다는 연속성이 중요한 서비스(e.g 실시간 스트리밍)에 자주 사용됨.
TCP와 UDP의 차이를 비유한다면, 좋은 기능이 다 들어있는 무거운 라이브러리와 필요한 기능만 들어있는 가벼운 라이브러리로 비교할 수 있음
체크섬(checksum)은 중복 검사의 한 형태로, 오류 정정을 통해, 공간(전자 통신)이나 시간(기억 장치) 속에서 송신된 자료의 무결성을 보호하는 단순한 방법.
Chapter2. 네트워크 계층 모델
네트워크 통신을 계층별로 나눈 이유에 대해 이해한다.
통신 과정에서 일어나는 데이터 캡슐화에 대해 이해한다.
Chapter2-1. OSI 7계층 모델
OSI 7계층 모델은 ISO(International Organization for Standardization)라고 하는 국제표준화기구에서 1984년에 제정한 표준 규격임
네트워크에 대한 표준 규격의 필요성
과거에는 같은 회사에서 만든 컴퓨터끼리만 통신이 가능했던 시절이 있었음
그래서 ISO에서는 제조사에 상관없이 공통으로 사용할 수 있는 네트워크 표준 규격을 정의했음
OSI 7계층 모델
각 컴퓨터간 데이터를 전송할 때 컴퓨터 내부에서는 여러가지 일을 한다. 이 모델은 하드웨어 및 소프트웨어가 수행하는 기능에 따라 이를 7개의 계층(또는 레이어라고도 부릅니다.)으로 구분함
네트워크를 이루고 있는 구성요소들을 7단계로 나누고, 각 계층의 표준을 정함
OSI 7계층 모델의 목적은 표준화를 통하여 포트, 프로토콜의 호환 문제를 해결하고, 네트워크 시스템에서 일어나는 일을 해당 계층 모델을 이용해 쉽게 설명할 수 있음
네트워크 관리자가 문제가 발생 했을 때 이것이 물리적인 문제인지, 응용 프로그램과 관련이 있는지 등 원인이 어디에 있는지 범위를 좁혀 문제를 쉽게 파악할 수 있음
각 계층은 다음과 같이 구분됨
계층 설명 e.g
1계층 - 물리 계층 - OSI 모델의 맨 밑에 있는 계층으로서, 시스템 간의 물리적인 연결과 전기 신호를 변환 및 제어하는 계층
- 주로 물리적 연결과 관련된 정보를 정의
- 주로 전기 신호를 전달하는데 초점을 두고, 들어온 전기 신호를 그대로 잘 전달하는 것이 목적 디지털 또는 아날로그로 신호 변경
2계층 - 데이터링크 계층 - 네트워크 기기 간의 데이터 전송 및 물리주소(e.g. MAC 주소)를 결정하는 계층 - 물리 계층에서 들어온 전기 신호를 모아 알아 볼 수 있는 데이터 형태로 처리함
- 이 계층에서는 주소 정보를 정의하고 출발지와 도착지 주소를 확인한 후, 데이터 처리를 수행 브리지 및 스위치, MAC 주소
3계층 - 네트워크 계층 - OSI 7 계층에서 가장 복잡한 계층 중 하나로서 실제 네트워크 간에 데이터 라우팅을 담당
- 이때 라우팅이란 어떤 네트워크 안에서 통신 데이터를 짜여진 알고리즘에 의해 최대한 빠르게 보낼 최적의 경로를 선택하는 과정을 말함 IP 패킷 전송
4계층 - 전송 계층 - 컴퓨터간 신뢰성 있는 데이터를 서로 주고받을 수 있도록 하는 서비스를 제공하는 계층
- 하위 계층에서 신호와 데이터를 올바른 위치로 보내고 신호를 만드는데 집중했다면, 전송 계층에서는 해당 데이터들이 실제로 정상적으로 보내지는지 확인하는 역할을 함
- 네트워크 계층에서 사용되는 패킷은 유실되거나 순서가 바뀌는 경우가 있는 데, 이를 바로 잡아주는 역할도 담당 TCP/UDP 연결
5계층 - 세션 계층 - 세션 연결의 설정과 해제, 세션 메시지 전송 등의 기능을 수행하는 계층 - 즉, 컴퓨터간의 통신 방식에 대해 결정하는 계층
- 즉, 양 끝 단의 프로세스가 연결을 성립하도록 도와주고, 작업을 마친 후에는 연결을 끊는 역할
6계층 - 표현 계층 - 응용 계층으로 전달하거나 전달받는 데이터를 인코딩 또는 디코딩하는 계층 - 일종의 번역기 같은 역할을 수행하는 계층 문자 코드, 압축, 암호화 등의 데이터 변환
7계층 - 응용 계층 - 최종적으로 사용자와의 인터페이스를 제공하는 계층으로 사용자가 실행하는 응용 프로그램(e.g. Google Chrome)들이 해당 계층에 속함 이메일 및 파일 전송, 웹 사이트 조회
데이터 캡슐화(OSI 7계층 모델의 데이터 송수신)
OSI 7계층 모델은 송신 측의 7계층과 수신 측의 7계층을 통해 데이터를 주고 받는다. 각 계층은 독립적이므로 데이터가 전달되는 동안에 다른 계층의 영향을 받지 않음
송신측(데이터 흐름: 상위 계층 -> 하위 계층)
데이터를 전송하는 쪽은 데이터를 보내기 위해서 상위 계층에서 하위 계층으로 데이터를 전달함.
이때 데이터를 상대방에게 보낼 때 각 계층에서 필요한 정보를 데이터에 추가하는데 이 정보를 헤더(데이터링크 계층에서는 트레일러)라고 한다.
그리고 이렇게 헤더를 붙여나가는 것을 캡슐화라고 함
마지막 물리 계층에 도달하며 송신 측의 데이터링크 계층에서 만들어진 데이터가 전기 신호로 변환되어 수신 측에 전송됨
수신측(데이터 흐름: 하위 계층 -> 상위 계층)
데이터를 받는 쪽은 하위 계층에서 상위 계층으로 각 계층을 통해 전달된 데이터를 받게됨
이때 상위 계층으로 데이터를 전달하며 각 계층에서 헤더(데이터링크 계층에서는 트레일러)를 제거해 나가는 것을 역캡슐화라고 함
역캡슐화를 거쳐 마지막 응용 계층에 도달하면 드디어 전달하고자 했던 원본 데이터만 남게 됨
Chapter2-2. TCP/IP 4계층 모델
TCP/IP 4계층 모델은 OSI 모델을 기반으로 실무적으로 이용할 수 있도록 현실에 맞춰 단순화된 모델임. 쉽게 말해 OSI 7계층 이론을 실제 사용하는, 즉 실용성에 기반을 둔 현대의 인터넷 표준이라고 할 수 있음
계층 설명 e.g
4계층: 어플리케이션 계층 OSI 계층의 세션 계층, 표현 계층, 응용 계층
- TCP/UDP 기반의 응용 프로그램을 구현할 때 사용 FTP, HTTP, SSH
3계층: 전송 계층 OSI 계층의 전송 계층 - 통신 노드간의 연결을 제어하고, 신뢰성 있는 데이터 전송을 담당 TCP/UDP
2계층: 인터넷 계층 OSI 계층의 네트워크 계층 - OSI 계층의 네트워크 계층에 해당하며 통신 노드 간의 IP 패킷을 전송하는 기능 및 라우팅을 담당 IP, ARP, RARP
1계층: 네트워크 인터페이스 계층 OSI 계층의 물리 계층과 데이터 링크 계층에 해당하며 물리적인 주소로 MAC을 사용 LAN, 패킷망 등에 사용됨
응용계층
네트워크 모델의 최상위 계층으로 최종적으로 사용자와의 인터페이스를 제공하는 계층
e.g) 사용자가 웹 서핑을 할 때에는 웹 브라우저를 사용하고 메일을 주고 받을 때는 Outlook과 같은 메일 프로그램을 사용하는 것
즉, 응용 계층은 이메일, 파일 전송, 웹 사이트 조회 등 어플리케이션에 대한 서비스를 사용자에게 제공하는 계층
이때 어플리케이션은 서비스를 요청하는 측(사용자 측)에서 사용하는 어플리케이션과 서비스를 제공하는 측의 어플리케이션으로 분류됨
일반적으로 서비스를 요청하는 측을 클라이언트, 서비스를 제공하는 측을 서버라고 함
웹 브라우저(e.g. Google Chrome)나 메일 프로그램(e.g. Outlook)은 사용자 측에서 사용하는 어플리케이션이니 클라이언트에 속하는 반면, 서비스를 제공하는 측인 서버에는 웹 서버 프로그램과 메일 서버 프로그램 등이 있음.
클라이언트와 서버 모두 응용 계층에서 동작함
Chapter3. HTTP
HTTP 메세지 구조를 이해한다.
HTTP의 무상태성과 비연결성에 대해 이해한다.
HTTP 헤더 중 바디를 설명하는 헤더인 표현헤더에 대해 이해한다.
HTTP 헤더 중 요청과 응답에서 주로 사용되는 헤더에 대해 이해한다.
HTTP 헤더 중 서버에 요청하는 컨텐츠를 협상할 수 있는 협상헤더에 대해 이해한다.
Chapter3-1. HTTP의 특징
HTTP 역사
HTTP/1.1, HTTP/2는 TCP 기반이며 HTTP/3는 UDP 기반 프로토콜임
HTTP 특징
클라이언트 서버 구조
무상태 프로토콜(Stateless), 비연결성(Connectionless)
HTTP 메세지
단순함, 확장 가능
클라이언트 서버 구조
Request-Response구조
클라이언트가 서버에 요청을 보내고, 응답을 대기.
서버는 요청에 대한 결과를 만들어 응답함
무상태 프로토콜(Stateless)
<-> 상태유지(Stateful)
상태유지 : 중간에 다른 점원으로 바뀌면 안됨
-> 항상 같은 서버가 유지돼야 함
-> 상태 유지가 되어야 하는 프로토콜이라면 클라이언트 A의 요청을 서버 1이 기억하고 있기 때문에 항상 서버 1이 응답해야 함
-> 만약, 중간에 다른 점원으로 바뀌면 상태정보를 다른 점원에게 미리 알려줘야 함
->만약 서버 1이 장애가 난다면 유지되던 상태 정보가 다 날아가 버리므로 처음부터 다시 서버에 요청해야 함
무상태 프로토콜
무상태 : 중간에 다른 점원으로 바껴도 됨
무상태에서는 고객이 자신의 주문을 기억하고 있다면 중간에 다른 점원으로 바뀌어도 주문을 할 수 있음
갑자기 고객이 증가해도 점원 대거 투입 가능
->갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있음
->무상태는 응답 서버를 쉽게 바꿀 수 있음 -> 무한한서버증설가능
클라이언트 A는 요청할 때 필요한 데이터를 다 담아서 보내기 때문에 아무 서버나 호출해도 됨
-> 만약 서버 1에 장애가 생기더라도 다른 서버에서 응답을 전달하면 되기 때문에 클라이언트는 다시 요청할 필요가 없음
그래서, 무상태 프로토콜이란 무엇인가?
서버가 클라이언트의 상태를 보존하지 않음
장점: 서버 확장성이 높음(스케일 아웃)
-> 무상태는 응답 서버를 쉽게 바꿀 수 있기 때문에 무한한 서버 증설이 가능
단점: 클라이언트가 추가 데이터 전송
한계: 모든 것을 무상태로 설계할 수 있는 경우도 있고, 그렇지 않은 경우도 있다.
e.g. 로그인이 필요 없는 단순한 서비스 소개 화면 같은 경우엔 무상태로 설계할 수 있지만
e.g. 로그인이 필요한 서비스라면 유저의 상태를 유지해야 되기 때문에 브라우저 쿠키, 서버 세션, 토큰 등을 이용해 상태를 유지합니다.
비연결성(Connectionless)
<-> 연결지향 Connection Oriented
연결을 유지하는 모델
TCP/IP의 경우 기본적으로 연결을 유지함
연결을 유지하는 모델에서는 클라이언트 1, 2는 요청을 보내지 않더라도 계속 연결을 유지해야 함
이 경우 연결을 유지하는 서버의 자원이 계속 소모됨
비연결성(Connectionless)
연결을 유지하지 않는 모델
비연결성을 가지는 HTTP에서는 실제로 요청을 주고받을 때만 연결을 유지하고 응답을 주고 나면 TCP/IP 연결을 끊는다.
이를 통해 최소한의 자원으로 서버 유지를 가능하게 함
HTTP 1.0 기준으로, HTTP는 연결을 유지하지 않는 모델임
일반적으로 초 단위 이하의 빠른 속도로 응답
트래픽이 많지 않고, 빠른 응답을 제공할 수 있는 경우, 비연결성의 특징은 효율적으로 작동함
e.g.한 시간 동안 수천 명이 서비스를 사용해도, 실제 서버에서는 초당 처리 요청 개수는 수십 개에 불과
-> 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않기 때문
비연결성의 한계
트래픽이 많고, 큰 규모의 서비스를 운영할 때 한계를 보임
TCP/IP 연결을 새로 맺어야 하므로 3 way handshake 시간이 추가됨
웹 브라우저로 사이트를 요청하면 HTML뿐만 아니라 자바스크립트, css, 추가 이미지 등 수많은 자원이 함께 다운로드됨. 해당 자원들을 각각 보낼 때마다 연결 끊고 다시 연결하고를 반복하는 것은 비효율적
따라서 지금은 HTTP 지속 연결(Persistent Connections)로 문제를 해결
HTTP/2, HTTP/3에서 더 많은 최적화가 이뤄짐
HTTP 초기 - 연결, 종료 낭비
HTTP 초기에는 각각의 자원을 다운로드하기 위해 연결과 종료를 반복해야 했음
HTTP 지속 연결
HTTP 지속 연결에서는 연결이 이루어지고 난 뒤 각각의 자원들을 요청하고 모든 자원에 대한 응답이 돌아온 후에 연결을 종료함
Chapter3-2. HTTP Headers
표현 헤더(Representation Headers)
HTTP 헤더와 바디
HTTP 바디에서는 메시지 본문(Message body)을 통해서 표현(Representation) 데이터를 전달함
여기서 데이터를 실어 나르는 부분(메시지 본문)을 페이로드(Payload)라 함.
표현은 요청이나 응답에서 전달할 실제 데이터
표현 헤더는 표현 데이터를 해석할 수 잇는 정보 제공
데이터 유형(html, json), 데이터 길이, 압축 정보 등
HTTP 헤더 (형식)
HTTP 헤더 (용도)
HTTP 헤더는 HTTP 전송에 필요한 모든 부가정보를 담기 위해 사용함
표현 헤더(자세히)
표현 헤더는 요청, 응답 둘 다 사용함
Content-Type
표현 데이터의 형식 설명
Content-Encoding
표현 데이터 인코딩
Content-Language
표현 데이터의 자연언어
Content-Length
표현 데이터의 길이
💡 Transfer-Encoding은 전송 시 어떤 인코딩 방법을 사용할 것인가를 명시함
그러나 현재는 Transfer-Encoding보다는 Content-Encoding을 사용하며, Transfer-Encoding을 사용하는 경우 chunked의 방식으로 사용
chunked 방식의 인코딩은 많은 양의 데이터를 분할하여 보내기 때문에 전체 데이터의 크기를 알 수 없음. 그 때문에 표현 데이터의 길이를 명시해야 하는 Content-Length 헤더와 함께 사용할 수 없습니다.
HTTP 요청/응답 주요 헤더
요청(Request)에서 사용되는 헤더
From: 유저 에이전트의 이메일 정보
-일반적으로 잘 사용하지 않음
-검색 엔진에서 주로 사용
-요청에서 사용
Referer: 이전 웹 페이지 주소
-현재 요청된 페이지의 이전 웹 페이지 주소
-A → B로 이동하는 경우 B를 요청할 때 Referer: A를 포함해서 요청
-Referer를 사용하면 유입경로 수집 가능
-요청에서 사용
-referer는 단어 referrer의 오탈자이지만 스펙으로 굳어짐
User-Agent: 유저 에이전트 애플리케이션 정보
-클라이언트의 애플리케이션 정보(웹 브라우저 정보, 등등)
-통계 정보
-어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능
-요청에서 사용
-e.g.
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/
537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36
Host: 요청한 호스트 정보(도메인)
-요청에서 사용
-필수 헤더
-하나의 서버가 여러 도메인을 처리해야 할 때 호스트 정보를 명시하기 위해 사용
-하나의 IP 주소에 여러 도메인이 적용되어 있을 때 호스트 정보를 명시하기 위해 사용
Origin: 서버로 POST 요청을 보낼 때, 요청을 시작한 주소를 나타냄
-여기서 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 발생한다.
-응답 헤더의 Access-Control-Allow-Origin와 관련
Authorization: 인증 토큰(e.g. JWT)을 서버로 보낼 때 사용하는 헤더
-“토큰의 종류(e.g. Basic) + 실제 토큰 문자”를 전송
-e.g.
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
응답(Response)에서 사용되는 헤더
Server: 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보
-응답에서 사용
-e.g.
Server: Apache/2.2.22 (Debian)
Server: nginx
Date: 메시지가 발생한 날짜와 시간
-응답에서 사용
-e.g.
Date: Tue, 15 Nov 1994 08:12:31 GMT
Location: 페이지 리디렉션
-웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 리다이렉트(자동 이동)
-201(Created): Location 값은 요청에 의해 생성된 리소스 URI
-3xx(Redirection): Location 값은 요청을 자동으로 리디렉션하기 위한 대상 리소스를 가리킴
Allow: 허용 가능한 HTTP 메서드
-405(Method Not Allowed)에서 응답에 포함
-e.g.
Allow: GET, HEAD, PUT
Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
-503(Service Unavailable): 서비스가 언제까지 불능인지 알려줄 수 있음
-e.g.
Retry-After: Fri, 31 Dec 2020 23:59:59 GMT(날짜 표기)
Retry-After: 120(초 단위 표기)
레퍼런스 [List of HTTP headers]
https://en.wikipedia.org/wiki/List_of_HTTP_header_fields
콘텐츠 협상 헤더
HTTP 헤더를 이용한 콘텐츠 협상에 대해 알아보자
콘텐츠 협상(Content negotiation)
클라이언트가 선호하는 표현 요청
협상 헤더는 요청 시에만 사용
레퍼런스
https://developer.mozilla.org/ko/docs/Web/HTTP/Content_negotiation
Accpet-Language
Accept-Language 헤더를 통해 클라이언트가 원하는 언어를 어떻게 서버에 요청할 수 있을까?
한국어 브라우저에서 특정 웹사이트에 접속했을 때 콘텐츠 협상(Accept-Language)이 적용되지 않았다면 서버는 요청으로 받은 우선순위가 없으므로 기본 언어로 설정된 영어로 응답.
클라이언트에서 Accept-Language로 KO를 작성해 요청한다면 서버에서는 해당 우선순위 언어를 지원할 수 있기 때문에 한국어로 된 응답을 돌려줌
Accpet-Language 협상
서버에서 지원하는 언어가 여러 개 이지만, 클라이언트가 최우선으로 선호하는 언어가 지원되지 않는 경우, 선호하는 언어에 대한 우선순위 요청하기!
협상 헤더에서는 원하는 콘텐츠에 대한 우선순위를 지정할 수 있음
1부터 0까지 우선순위를 부여하면 이를 토대로 서버는 응답을 지원함
결과
1순위인 한국어를 서버에서는 지원하지 않지만 2순위인 영어를 지원함
따라서, 서버에서는 독일어보다 우선순위에 있는 영어로 응답을 주게 됩
Chapter4. Web Cache
웹 캐시와 이를 검증할 수 있는 여러 헤더와 프록시 캐시에 대해 학습한다.
캐시(cache)는 컴퓨터 과학에서 데이터나 값을 미리 복사해 놓는 임시 장소를 가리킴
웹에서도 동일한 요청의 경우 같은 데이터를 다시 다운로드하지 않고 이를 웹 캐시로 저장하여 빠르게 불러올 수 있음
개인의 컴퓨터에 저장하는 프라이빗 캐시뿐만 아니라 여러 유저에게 공통적으로 보여지는 데이터의 경우 프록시 서버에 별도로 캐시를 저장하여 사용자 경험을 향상시킬 수 있음
학습목표
웹 캐시의 필요성에 대해 이해한다.
Cache-Control: max-age=60이 어떤 의미인지 이해한다.
요청에서 사용하는 If-Modified-Sinse 헤더와 응답에서 사용하는 Last-Modified 헤더에 대해 이해한다.
요청에서 사용하는 If-None-Match헤더와 응답에서 사용하는 Etag 헤더에 대해 이해한다.
프록시 서버의 필요성에 대해 이해한다.
프라이빗 캐시와 프록시 캐시의 차이에 대해 이해한다.
Cache-Control 헤더의 값인 no-cache와 must-revalidate의 차이에 대해 이해한다.
캐시
컴퓨터 과학에서, 데이터나 값을 미리 복사해 놓는 임시 장소
캐시가 없을 때
같은 이미지를 다시 요청하더라도 첫 번째처럼 똑같이 1.1M의 응답을 보낸다.
이 경우
logo.jpg 데이터가 변경되지 않아도 계속 데이터를 새로 다운받아야 함
인터넷 네트워크는 매우 느리고 비쌈
브라우저 로딩 속도가 느림
느림 사용자 경험 제공
-> 브라우저가 이를 저장하는 방법은 없을까?
캐시 적용
캐시에 데이터를 미리 복사해 놓으면 계산이나 접근 시간 없이 더 빠른 속도로 데이터에 접근할 수 있음
브라우저에 캐시를 저장할 땐 헤더에 cache-control 속성을 통해 캐시가 유효한 시간을 지정할 수 있음
캐시의 접근 시간에 비해 원래 데이터를 접근하는 시간이 오래 걸리는 경우나 값을 다시 계산하는 시간을 절약하고 싶은 경우에 사용
첫번째요청
응답을 받았을 때 브라우저 캐시에 해당 응답 결과를 저장하며 이는 60초간 유효함
캐시 적용 - 캐시 시간이 초과했을 경우
두번째요청
두 번째 요청에선 캐시를 우선 조회하게 됨
캐시가 존재하고 아직 60초가 지나지 않아 유효한 캐시라면 해당 캐시에서 데이터를 가져옴
캐시 쓰는 이유
캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 됨
비싼 네트워크 사용량을 줄일 수 있음
브라우저 로딩 속도가 매우 빠름
빠른 사용자 경험 제공
세번째요청
근데 만약 캐시의 유효시간이 초과한다면?
이 경우에 다시 서버에 요청을 하고 60초간 유효한 logo.jpg 이미지를 응답받는다
이때 다시 네트워크 다운로드가 발생하게 됨
즉, 캐시 유효 시간이 초과하면, 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신함. 이때 다시 네트워크 다운로드가 발생함.
응답 결과를 브라우저가 렌더링 하면 브라우저 캐시는 기존 캐시를 지우고 새 캐시로 데이터를 업데이트함
이 과정에서 캐시 유효 시간이 다시 초기화됨
Chapter4-1. 캐시 검증 헤더
캐시를 제어할 수 있는 검증 헤더와 이를 이용한 조건부 요청에 대해 알아보자
앞서 살펴본 캐시의 경우 유효시간이 초과하면 다시 요청을 보내 새로운 데이터로 캐시를 업데이트 함.
만약 캐시 유효시간이 지났지만 서버 데이터가 변경되지 않아서, 해당 데이터를 써도 되는 상황이라면 이를 검증하고 사용하는 방법은 없을까?
Last-Modified와 If-Modified-Since
첫번째요청
검증 헤더 Last Modified를 이용해 캐시의 수정시간을 알 수 있음
Last Modified는 데이터가 마지막으로 수정된 시간 정보를 헤더에 포함함
이로 인해 응답 결과를 캐시에 저장할 때 데이터 최종 수정일도 저장됨
두번째요청
캐시 유효기간이 초과되더라도 If-Modified-Since 헤더를 이용해 조건부 요청을 할 수 있음
서버의 해당 자료의 최종 수정일과 비교해서 데이터가 수정이 안되었을 경우 서버는 응답 메시지에 이를 담아서 알려줌
이때 HTTP Body는 응답 데이터에 없으며 상태 코드는 304 Not Modified로 변경된 것이 없다는 뜻임
전송 데이터에 바디가 빠졌기 때문에 헤더만 포함된 0.1M만 전송됨
클라이언트에서는 해당 응답을 받은 뒤 캐시를 갱신해 주고 다시 일정 시간(60초) 동안 유효하게 됨
정리
캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않았다면?
304 Not Modified + 헤더 메타데이터만 응답(바디x)
클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타데이터를 갱신
클라이언트는 캐시에 저장돼 있는 데이터 재활용
결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드
-> 매우 실용적인 해결책.
*메타데이터: 데이터를 설명하는 데이터
단점
1초 미만 단위로 캐시 조정 불가
날짜 기반의 로직 사용
데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우
서버에서 별도의 캐시 로직을 관리하고 싶은 경우
e.g. 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우
ETag와 If-None-Match
Last-Modified와 If-Modified-Since보다 좀 더 간단한 방식으로 ETag와 If-None-Match 검증 헤더가 있음
서버에서 완전히 캐시를 컨트롤하고 싶은 경우 ETag를 사용할 수 있음
작동 방식
서버에서 헤더에 ETag를 작성해 응답한다.
클라이언트의 캐시에서 해당 ETag 값을 저장한다.
만약 캐시 시간이 초과돼서 다시 요청을 해야 하는 경우라면 이때 ETag 값을 검증하는 If-None-Match를 요청 헤더에 작성해서 보낸다.(조건부요청)
서버에서 데이터가 변경되지 않았을 경우 ETag는 동일하기에 그래서 If-None-Match는 거짓이 됨
이 경우 서버에서는 304 Not Modified를 응답하며 이때 역시 HTTP Body는 없음
브라우저 캐시에서는 응답 결과를 재사용하고 헤더 데이터를 갱신함.
정리
Cache-Control : 캐시 지시어(directives)
Expires : 캐시 만료일 지정(하위 호환)
검증 헤더와 조건부 요청 헤더 - 정리
Chapter4-2. 프록시 캐시
프록시 서버란?
클라이언트가 다른 네트워크 서비스에 간접적으로 접속할 수 있게 하는 컴퓨터 시스템이나 응용프로그램을 의미함
클라이언트와 서버 사이에 대리로 통신을 수행하는 것을 프록시(Proxy)
그 중계 기능을 하는 서버를 프록시 서버라고 함
클라이언트, 혹은 반대로는 서버가 다른 네트워크에 간접적으로 접속할 수 있기 때문에, 보안, 캐싱을 통한 성능, 트래픽 분산 등의 장점을 가짐
프록시 캐시
원 서버에 직접 접근하는 경우
한국에 있는 클라이언트에서 특정 데이터가 필요한 상황인데 해당 데이터의 원 서버가 미국에 있다고 가정해보자.
한국에서 미국까지 직접 접근하여 이미지를 가져오는데 0.5초가량 걸린다고 하면 한국에 있는 클라이언트는 모두 0.5초가량을 기다려야 해당 이미지를 받을 수 있음
하지만 우리는 유튜브와 같은 해외 사이트에서 위와 같은 불편한 없이 빠르게 영상을 시청할 수 있음.
-> 어떻게 이게 가능 한가?
프록시 캐시 도입
이는 클라이언트와 원 서버 사이에 위치한 프록시 캐시 서버를 도입했기 때문
한국에 프록시 캐시서버를 두고 한국의 클라이언트는 프록시 캐시서버를 통해 자료를 가져오도록 함
여러 사람이 찾은 자료일수록 이미 캐시에 등록되어 있기에 빠른 속도로 자료를 가져올 수 있고, 또, 같은 국내에 있기에 원서버에 접근하는 것보다 훨씬 빠른 속도에 자료를 가져올 수 있음
💡 이때 클라이언트에서 사용하고 저장하는 캐시를 private 캐시라 하며 프록시 캐시 서버의 캐시를 public 캐시라 한다.
Cache-Control
프록시 캐시와 관련된 헤더
캐시 지시어(directives) - 기타
캐시 무효화
클라이언트가 캐시를 적용하지 않아도 임의로 브라우저가 캐시를 적용하는 경우, 특정 페이지에서 캐시가 되면 안 되는 정보(e.g. 통장 잔고)가 있다면 어떻게 이를 무효화할 수 있을까?
캐시를 무효화할 수 있는 헤더
캐시 지시어(directives)
만약 캐시를 무효화를 확실하게 해야 하는 경우라면, Pragma와 같은 하위 호환까지 포함해 아래와 같이 캐시 지시어를 모두 넣어야함
no-cache vs must-revalidate
no-cache와 must-revalidate 모두 원 서버에 검증해야 하지만 그에 대한 응답에 대해 다른 점이 있음
no-cache 기본 동작
캐시 서버 요청을 하면 프록시 캐시 서버에 도착하면 no-cache인 경우 원 서버에 요청을 하게 됨. 그리고 원 서버에서 검증 후 304 응답을 하게 됨
원 서버 접근불가시 : no-cache
만약 프록시 캐시 서버와 원 서버 간 네트워크 연결이 단절되어 접근이 불가능하다면, no-cache에서는 응답으로 오류가 아닌 오래된 데이터라도 보여주자라는 개념으로 200OK으로 응답함
원 서버 접근불가시 : must-revalidate
must-revalidate라면 원 서버에 접근이 불가할 때 504 Gateway Timeout 오류를 보냄
예를 들어, 통장 잔고 등 중요한 정보를 원 서버로부터 못 받았다고 해서 예전 데이터로 뜬다면 큰 문제가 생기기 때문에 이런 경우 must-revalidate를 써야 함
