HTTP 웹 기본 지식

Seung jun Cha·2022년 6월 27일

스프링

1. IP(인터넷 프로토콜)

1-1 역할

라우터나 방화벽 등 네트워크 장치를 식별하기 위한 서버의 주소로 패킷을 전송하는 등 네트워크 간의 통신을 가능하게 한다. 패킷은 노드에서 노드로 전송된다.
- L3 IP 패킷 : 패킷은 네트워크에서 전송되는 L3 수준에서 정의되는 데이터의 단위로 헤더(머리) + 페이로드(내용/데이터) + 트레일러(꼬리)로 구성된다.
- 노드 : 유선 또는 무선으로 연결되어 네트워크 상 통신이 가능한 장치를 말한다.
- 프로토콜 : 네트워크에서 통신하기 위해 정의된 규칙과 규약을 말한다. (ex) HTTPS, SMTP, SSL
OSI 7 Layer / TCP/IP 모델
컴퓨터간의 데이터 통신을 단계적으로 처리하기 위해 표준화한 구조로 7개의 계층으로 나누어져 있고 각 계층마다 새로운 Header가 붙는다 실제로 이런 구조로 사용되지는 않는다
Application - presentation - session - transport - network - data link - physical

물리계층 : 데이터를 전기 신호로 변환하여 송수신하는 역할을 한다.
데이터링크 계층 : 물리 계층에서 전송된 데이터를 프레임(frame) 단위로 분할하고 데이터의 흐름과 접근을 관리한다. 프레임은 데이터링크 계층에서 정의되는 데이터 단위이다.
네트워크 계층 : 라우팅과 네트워크 간의 패킷 전달을 담당한다. 라우팅은 목적지까지 데이터를 전송하는데 적절한 경로를 선택하는 과정을 의미한다.
전송 계층 : 서버와 클라이언트 간의 데이터 전송, 데이터의 분할, 오류 검출 및 복구, 흐름 제어 등을 담당합니다. 포트번호로 어떤 프로그램에 데이터를 전달해야하는지 식별한다.
세션 계층 : 세션을 설정, 유지 및 종료하는 역할을 한다.
표현 계층 : 데이터의 형식 변환, 암호화, 압축 등의 기능을 수행하여 데이터 호환성을 제공한다.
응용 계층 : 사용자와 응용 프로그램 간의 인터페이스를 제공한다.

1-2 한계

비연결성 : 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
비신뢰성 : 중간에 패킷이 사라지거나, 순서대로 오지 않을수도 있음
(용량이 커서 메시지를 끊어서 보내는 경우, 보낸 순서대로 도착하지 않음)
프로그램의 구분 : 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상인 경우에 구분

2. TCP, UDP, PORT, DNS

LAN카드까지(NIC)까지는 하드웨어이고, MAC 주소(48bit)를 가진다.
TCP/IP는 소프트웨어 중 커널모드이다.
TCP/IP를 추상화 한 인터페이스 파일을 SOCKET이라고 한다. USER MODE에서 KENEL MODE로 파일이나 메시지를 넘겨주기 위해 커널에 있는 tcp/ip를 추상화한 인터페이스로, 이 SOCKET을 열고 닫는 것이 중요하다.

L1
L2 : Ethernet , 식별자는 MAC주소 (랜카드를 식별한다 / LAN Card = NIC), 데이터 단위는 Frame
L3 : Internet , 식별자는 IP주소 (HOST를 식별한다. -> HOST는 네트워크에 연결된 컴퓨터를 의미한다.), 데이터 단위는 Packet
L4 : Tcp, Udp , 식별자는 port번호 (프로세스 또는 L2인터페이스 또는 네트워크 서비스), 데이터 단위는 Tcp는Segment Udp는 datagram

세그먼트 순서가 1씩 증가하는 것이 아니라 byte 만큼 증가한다.
1 -> 2 -> 3 x
첫번째 세그먼트의 byte가 400이라면 두번째 세그먼트는 401
1 -> 401

L5 : SSL (TLS)
L6
L7 : HTTP

2-1 TCP 특징

클라이언트와 서버간의 논리적인 연결 설정과정이 있는 연결지향 프로토콜이다.
연결 요청 과정
- 프로세스는 자신의 식별자인 PID를 가진다.
- 프로세스가 소켓을 생성하고 오픈한다.
- 운영체제가 소켓에 TCP port번호를 부여한다.
- 서버의 아이피와 포트번호를 알아야 연결이 가능하다. 그리고 소켓이 열리고 연결대기 상태여야 한다.
TCP 헤더

TCP 헤더 : 32bit
Port번호의 경우의 수 : 0 ~ 65535 / 0번과 65535번은 없음
Souce Port : 16bit

HTTP/1.1(KeepaliveTimeout), HTTP/2 버전 사용

3 way handshake : TCP 연결을 위해 클라이언트와 서버 간에 세 개의 패킷을 교환하는 과정이다. 연결된 것을 확인하고 전송 (연결형 프로토콜) 응답을 주고 받는 형태, 순서보장

(1) 클라이언트가 연결 요청 시, 임의의 숫자인 시퀀스 번호(SYN)를 패킷에 넣어 보낸다.

(2) 서버가 요청을 수락 할 때는 서버가 임의의 숫자를 시퀀스 번호(SYN)와 클라이언트가 보낸 시퀀스 번호에 +1을 한 값인 ACK 2개의 번호를 패킷에 넣어서 클라이언트에게 보낸다

(3) 클라이언트가 수락응답할 때는 서버가 보낸 SYN번호에 +1을 한 ACK로 응답한다.

(4) 처음에 연결을 할 때만 syn 번호를 교환하고, 연결을 유지하며 데이터를 전달할 때는 ack 번호만 주고 받는다.

(5) 연결과정에 정책을 교환하는 과정이 있다. 그 중 가장 중요한 것이 MSS(최대 세그먼트 사이즈) 결정이다.

데이터 전달 보증 : 패킷이 전달되었는지, 아닌지 확인가능, 전송 받는 쪽에서 ACK번호를 어디까지 받았는지 ACK넘버를 상대방에게 전송
패킷 순서 보장 : 패킷에 포함된 시퀀스 번호와 ACK 번호는 연결을 유지하는동안 숫자가 증가하기 때문에, 이를 확인하여 패킷의 순서를 보장받을 수 있다. 이 번호들을 확인해서 올바른 패킷의 순서를 확인하거나, 데이터의 손실이과 중복을 파악할 수 있다.

4-way handshack : TCP 연결 해제 과정 (FIN, ACK 를 사용)
(1) 클라이언트는 연결 종료를 요청하기 위해 FIN(종료 요청) 패킷을 서버로 전송합니다.
(2)서버는 클라이언트의 연결 종료 요청을 받고, ACK(응답 확인) 패킷을 클라이언트에게 전송하여 요청을 확인합니다. 이때 서버는 아직 자신의 데이터를 모두 전송하지 않았을 수 있으므로, 데이터 전송이 완료될 때까지 일시적으로 연결을 유지합니다.
(3)서버는 데이터의 전송이 완료되었다는 것을 나타내기 위해 FIN 패킷을 클라이언트로 전송합니다.
(4)클라이언트는 서버의 연결 종료 요청을 받고, ACK 패킷을 서버로 전송하여 요청을 확인합니다. 클라이언트는 이후에도 데이터를 전송하지 않을 것을 나타내기 위해 연결을 종료합니다.

2-2 UDP 특징

HTTP/3 버전 사용

비연결형 프로토콜 : 논리적인 연결 설정 과정과 해제과정 없이 데이터를 전송한다. 그래서 TCP보다 오버헤드도 낮다.
단방향 통신 : 데이터를 전송하는 송신자와 데이터를 수신하는 수신자 간의 단방향 흐름이 있다.
신뢰도가 낮음 : SYN과 ACK를 주고 받지 않기 때문에 데이터의 순서나 데이터의 손실을 확인할 수 없다.
UDP 헤더 = IP + Port + 체크섬

데이터 효율성을 중시하여 데이터의 일부가 유실되어도 문제없는 스트리밍 서비스에 이용, 동일 네트워크에 연결된 모든 컴퓨터에 데이터 송신 가능한 브로드캐스팅을 지원한다. DNS서버와 프로그램과의 통신에도 UDP를 이용한다. DNS 서버는 받은 UDP 패킷에 포함된 호스트 네임을 확인하고, 해당 호스트의 IP 주소를 포함한 UDP 패킷으로 응답한다.

2-3 PORT

한 번에 두 개 이상의 IP와 연결되어 있을 때, TCP/IP 패킷에 들어있는 Port 정보를 사용해 패킷을 구분한다.

2-4 DNS, VIP, GSLB, FQDN

도메인 : 네트워크 상에서 컴퓨터를 식별하는 호스트명
- www.naver.com 에서 www는 host name / naver.com은 domain name이다
트리구조의 도메인 네임 체계
PC의 ip 설정에 DNS 서버주소가 포함되어있다.
IP를 기억하기 힘들고, IP가 변경될 수 있다는 점을 고려해서, 도메인 네임 시스템(Domain Name System)으로 도메인 명으로 IP 주소를 가져와 해당 서버에 접속할 수 있게 해준다 이때 가져오는 IP 주소는 유효기간을 가지고 있어서, 기간이 지나면 다시 도메인 명으로 IP주소를 가져와야한다.
이렇게 해당 사이트에 접속하게되면 해당 아이피를 DNS Cache에 저장하게된다. 유효기간 동안은 도메인에 접근할 때 DNS Cache의 IP주소를 가져와서 사용한다.
- 공유기와 DNS서버의 ip주소가 같으면 공유기가 DNS서버의 포워드 기능을 해서 공유기가 도메인 주소를 알려주기도 한다.
- hosts 파일에 도메인 정보를 저장할 수도 있다.

VIP : 다수의 서버 IP 중 대표 서버 IP로 로드밸런싱 역할을 한다. 대표 IP로 들어온 요청을 하위 서버에 분산하는 것이다. 로드밸런싱이란 네트워크나 서버 환경에서 트래픽이나 작업 부하를 여러 대의 서버에 균등하게 분산시켜주는 기술을 말한다.
GSLB : DNS 기반이라서 IP가 아닌 도메인을 가진다. 로드밸런싱을 할 때, 서버의 위치를 고려하고, 문제가 생긴 서버에는 밸런싱을 하지 않는 기능을 제공한다.
FQDN :

2-5 TCP 제어

2-5-1 흐름제어

클라이언트의 상태를 고려하여 데이터 전송량이나 전송 속도를 조절하기 위한 메커니즘이다.
슬라이딩 윈도우 : 패킷을 하나씩 주고 받으며 ACK를 기다리는 것이 아닌, 수신자의 윈도우 사이즈를 확인해서 사이즈만큼 ACK 없이 연속해서 송신한다. 윈도우의 앞부분이 ACK를 받으면 윈도우가 뒤로 이동하고 추가된 뒷부분의 전송이 시작된다.
윈도우 사이즈는 SYN과 SYN/ACK 사이의 시간인 RTT(Round Trip Time)을 측정해서, 이를 기반으로 윈도우사이즈를 재설정한다.
윈도우 내의 데이터만을 전송하므로 데이터의 혼잡을 방지하고, 수신 측은 윈도우 외의 데이터를 무시함으로써 데이터의 순서를 보장한다. 또하 ACK를 주고받기 때문에 데이터의 손실도 파악할 수 있다.
단점은 윈도우 사이즈를 동적으로 조절하기 위해서는 적절한 알고리즘이 필요한데 알고리즘이나 네트워크 상태에 따라 흐름제어가 제대로 작동하지 않을 수 있다는 점이다.

2-5-2 혼잡제어

네트워크 혼잡상태를 고려하여 데이터 전송량이나 전송속도를 제한하는 것으로 송신 측은 수신자윈도우와 혼잡 윈도우 중 작은 값을 사용한다.
수신자 윈도우(RWND) : 수신자 측이 처리할 수 있는 데이터의 양을 고려하여 정한 윈도우 크기로 이 값을 송신자에게 전달한다.
혼잡 윈도우(CWND) : 송신자 측이 네트워크 혼잡상태를 고려하여 정한 윈도우 크기

AIMD : 송신 측의 전송 속도를 조절하는 방식으로 CWND를 1로 설정하고 패킷이 성공적으로 도착하여 ACK를 받으면 CWND의 윈도우 크기를 1개씩 늘린다. 전송에 실패하여 일정시간 내에 ACK를 받지 못하면 CWND / 2 윈도우 크기를 너무 조금씩 늘리기 때문에 제대로 된 속도로 통신하기까지 시간이 오래 걸린다.
SLOW START : 윈도우 사이즈를 초기값으로 설정, ACK를 받으면 기존의 윈도우 사이즈의 2배, 받지 못하면 CWND = 1 (초기값)

2-6 TCP와 UDP의 차이점 정리

TCP
- 연결 지향 프로토콜로 데이터 전송 중 손실된 패킷을 검출할 수 있고, 데이터의 순서를 보장할 수 있다. 양방향 통신으로 클라이언트와 서버가 데이터를 주고 받을 수 있다.
UDP
- 연결 설정 단계가 없는 비연결성 프로토콜이다. 단방향 통신으로 데이터 전송속도는 빠르지만, 전송 중 데이터가 손실될 수 있고, 순서를 보장하지 않는다.

3. URI, URL

3-1 개념

Resource : html, css, js, img 등의 파일을 의미한다.
URI(Resource Identifier) : 리소스의 식별자 , URL과 URN을 포함하는 개념
URL(Resource Locator) : 리소스의 위치
URN(Resource Name) : 리소스의 이름(ISBN 같은 것) , 리소스의 위치는 바뀔 수 있어도 이름은 바뀌지 않는다 , 실무에서는 사용하지 않음

여기서 리소스는 웹에서 접근하고 식별할 수 있는 모든 객체나 정보를 말한다.

3-2 문법

scheme : 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙인 프로토콜을 사용
http는 80포트 , https는 443 포트를 주로 사용 -> http, https를 사용하는 경우 포트는 생략가능
userinfo@ : 사용자정보로 거의 사용하지 않음
host : 도메인명 또는 IP 주소를 직접 사용가능
PORT : 일반적으로 생략, 생략시 http는 80, https는 443 , 특정 서버에 접근해야 할 때 입력
리소스 경로(path) : 예) /members/100, /items/iphone12
query : key=value 형태 ?로 시작, &로 추가 가능
fragment : 사용안함

4. HTTP 기본

HTML문서를 전송 받기 위해 만들어진 응용 프로그램 계층 통신 프로토콜(L7)
L5 이상부터는 Socket과 stream을 사용하기 때문에 시작은 있지만 끝은 명확하지 않은데 언제 끝나는지 HTTP에 들어있다.

4-1 Stateless , Connectionless

Stateless
서버가 클라이언트의 상태를 보존하지 않는 무상태 프로토콜로 이전 요청과 무관하게 각각의 요청은 독립적으로 처리된다.
Stateless 하게 설계하는 것이 기본이다. 상태 정보를 유지해야 할 필요가 있는 경우, 세션과 쿠키를 사용하여 상태를 관리할 수 있다.

Connectionless
HTTP는 기본적으로 요청과 응답을 처리한 후에 연결을 종료해서 자원이 계속 소모되지 않게 한다.

4-2 HTTP, HTTPS의 특징, 차이

개념 : 텍스트 기반의 통신 규약으로 인터넷에서 데이터를 주고받을 수 있는 프로토콜
HTTP는 따로 암호화 과정을 거치지 않기 때문에 중간에 패킷을 가로챌 수 있고, 수정할 수 있어 보안이 취약하다.
이를 보완하기 위해 나온 것이 HTTPS이고, 중간에 암호화 계층을 거쳐서 패킷을 암호화한다.

4-3 HTTP 메시지

HTTP 요청 메시지
- 시작라인 : HTTP 메서드 (GET, POST 등), 요청 대상 (/search?q=hello&hl=ko) ,HTTP Version
- 헤더 : header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용)
- HTTP 메시지 바디 : byte로 표현할 수 있는 모든 데이터 전송 가능
HTTP 응답 메시지
- 시작라인 : HTTP 버전, HTTP 상태 코드, 이유 문구
- 헤더 : header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용) , HTTP 전송에 필요한 모든 부가정보
- HTTP 메시지 바디 : byte로 표현할 수 있는 모든 데이터 전송 가능

4-4 HTTP API

Rest API

자원을 URI로 표현하고, 자원에 대한 행위를 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.
HTTP 메서드
- GET : 서버로부터 데이터를 요청합니다. 주로 정보를 조회하는 용도로 사용합니다. GET 요청은 캐시될 수 있으며 서버에 요청 데이터를 전달하고 싶을 때는 key-value 형태의 쿼리 파라미터로 전달합니다.
- POST : HTTP 메시지 바디로 요청 데이터 전달해서 처리를 요청, 새로운 데이터를 생성하거나 서버의 상태를 변경
  POST는 멱등하지 않기 때문에 동일한 요청을 보낼 때마다 새로운 데이터를 생성한다.
- PUT : 서버에 데이터를 전송해서 전체 데이터를 완전히 대체하고 해당 데이터가 없으면 생성한다. 클라이언트가 전체 데이터를 보내야 하기 때문에, 누락된 필드가 있으면 기본값으로 설정되거나 빈 값으로 업데이트될 수 있습니다.
  PUT은 멱등하기 때문에 동일한 요청을 보내면 매번 동일한 데이터를 반환한다.
- PATCH : 서버에 데이터를 전송하여 해당 데이터를 부분적으로 수정하는 업데이트를 수행합니다.
- HEAD: GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
- OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
- CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정
- TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

4-5 HTTP 메서드의 속성

safe(안전)
호출을 해도 리소스를 변경하지 않는다
Idempotent(멱등)
같은 HTTP 메서드를 몇 번을 호출하든 결과가 같다
- GET: 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.
- PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
- DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.
- POST: 멱등이 아니다! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.
  => 활용 : 자동복구 메커니즘, 서버가 TIMEOUT 등으로 정상 응답을 못주었을 때, 클라이언트가 같은 요청을 다시 해도 되는지의 판단근거
  => 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지는 않는다.
캐시가능
응답 결과 리소스를 캐시해서 사용해도 되는가?
- GET, HEAD, POST, PATCH 캐시가능, 실제로는 GET, HEAD 정도만 캐시로 사용
- POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음

5. HTTP 상태코드

클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
- 1xx (Informational): 요청이 수신되어 처리중
- 2xx (Successful): 요청 정상 처리
- 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요
- 4xx (Client Error): 클라이언트의 요청 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음
- 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함

5-1 2xx

200 : OK 요청 성공
201 Created : 요청 성공해서 새로운 리소스가 생성됨, 생성된 리소스는 응답의 Location 헤더 필드로 식별
202 Accepted : 요청이 접수되었으나 처리가 완료되지 않았음, 배치 처리 같은 곳에서 사용
204 No Content : 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음, 웹 문서 편집기에서 save 버튼

5-2 3xx

요청을 완료하기 위해 유저 에이전트의 추가 조치 필요
웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동
리다이렉션의 종류 : 영구, 일시, 특수
- 영구 리다이렉션
  특정 리소스의 URI가 영구적으로 이동 (301, 308)
  원래의 URL를 사용X, 검색 엔진 등에서도 변경 인지
  - 301 Moved Permanently : 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음
  - 308 Permanent Redirect : 301과 기능은 같음
    리다이렉트시 요청 메서드와 본문 유지
    (처음 POST를 보내면 리다이렉트도 POST 유지)
- 일시 리다이렉션
  
  리소스의 URI가 일시적으로 변경, 따라서 검색 엔진 등에서 URL을 변경하면 안됨
  - 302 Found : 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)
  - 307 Temporary Redirect : 302와 기능은 같음 ,리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다. MUST NOT)
  - 303 See Other : 302와 기능은 같음, 리다이렉트시 요청 메서드가 반드시 GET으로 변경
  - 304 Not Modified : 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서 클라이언트는 로컬PC에 저장된 캐시를 재사용한다. (캐시로 리다이렉트)
    304 응답은 응답에 메시지 바디를 포함하면 안된다. (로컬 캐시를 사용해야 하므로)
- PRG: Post/Redirect/Get : 응답코드를 200이 아닌 302나 303으로 줌

@PostMapping("/add")
public String addItemV6(Item item, RedirectAttributes redirectAttributes) {
 	Item savedItem = itemRepository.save(item);
 	redirectAttributes.addAttribute("itemId", savedItem.getId());
 	redirectAttributes.addAttribute("status", true);
 	return "redirect:/basic/items/{itemId}";
}

5-3 4xx

클라이언트 오류, 클라이언트의 요청에 잘못된 문법, 요청 등으로 서버가 요청을 수행할 수 없음
- 400 Bad Request : 클라이언트의 잘못된 요청
- 401 Unauthorized : 클라이언트가 해당 리소스에 대한 인증(로그인)이 필요함,
  401 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명
- 403 Forbidden : 서버가 요청을 이해했지만 승인을 거부함, 주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우
- 404 Not Found : 요청 리소스를 서버에서 찾을 수 없음 또는 해당 리소스를 숨기고 싶음

5-4 5xx

서버 문제로 오류 발생, 서버에 문제가 있기 때문에 재시도 하면 성공할 수도 있음
500 Internal Server Error : 서버 문제로 오류 발생, 애매하면 500 오류
503 Service Unavailable : 서비스 이용 불가, 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음, Retry-After 헤더 필드로 얼마 뒤에 복구되는지 보낼 수도 있음

6. HTTP 헤더

6-1 표현

표현은 요청이나 응답에서 전달할 실제 데이터, 표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공
표현 헤더
- Content-Type : 표현 데이터의 형식 설명 , 미디어 타입, 문자 인코딩
- Content-Encoding : 표현 데이터 인코딩 , 데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가, 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축 해제
- Content-Language : 표현 데이터의 자연 언어(ko, en ..)
- Content-Length : 표현 데이터의 길이, Transfer-Encoding(전송 코딩)을 사용하면 Content-Length를 사용하면 안됨

6-2 협상

- 클라이언트가 선호하는 표현 요청, 협상 헤더는 요청시에만 사용

협상과 우선순위1 : Quality Values(q)
0~1 사이의 값으로 클수록 높은 우선순위를 가진다, 생략하면 1
ex) Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.

6-3 일반정보

• From: 유저 에이전트의 이메일 정보
• Referer: 현재 요청된 페이지의 이전 웹 페이지 주소, A -> B로 이동하는 경우 B를 요청할 때 Referer: A 를 포함해서 요청, Referer를 사용해서 유입 경로 분석 가능
• User-Agent: 클라이언트의 애플리케이션 정보, 어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능
• Server: 요청을 처리하는 오리진 서버의 소프트웨어 정보, 응답에서 사용
• Date: 메시지가 생성된 날짜, 응답에서 사용

6-3 특별정보

• Host: 클라이언트가 요청한 호스트 정보(도메인), 필수값으로 하나의 IP 주소에 여러 도메인이 적용되어 있을 때 사용됨
• Location: 페이지 리다이렉션
• Allow: 허용 가능한 HTTP 메서드
• Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

6-4 쿠키

Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답)
Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달
필요성
• HTTP는 무상태(Stateless) 프로토콜이다.
• 클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊어진다.
• 클라이언트가 다시 요청하면 서버는 이전 요청을 기억하지 못한다.
쿠키의 도메인 : 예) domain=example.org
명시: 명시한 문서 기준 도메인 + 서브 도메인 포함(dev.example.org도 쿠키 접근)
생략: 현재 문서 기준 도메인만 적용
쿠키의 경로 : 지정한 경로를 포함한 하위 경로 페이지만 쿠키 접근
일반적으로 path=/ 루트로 지정
보안 : Secure, HttpOnly, SameSite
- Secure
  - 쿠키는 http, https를 구분하지 않고 전송
  - Secure를 적용하면 https인 경우에만 전송
- HttpOnly
  - XSS 공격 방지
  - 자바스크립트에서 접근 불가(document.cookie)
  - HTTP 전송에만 사용
- SameSite
  - XSRF 공격 방지
  - 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송

6-5 캐시

캐시가 없을 때, 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다
캐시 유효 시간이 초과하면, 서버를 통해 데이터를 다시 다운받고, 캐시를 갱신한다
캐시 유효 시간이 초과해서 서버에 다시 요청하면 다음 두 가지 상황이 나타난다.

6-5-1 if-modified-since : Last-Modified

서버에서 기존 데이터를 변경함
서버에서 기존 데이터를 변경하지 않음 : 데이터를 전송하는 대신에 저장해 두었던 캐시를 재사용 할 수 있다. 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법 필요

서버가 요청받은 데이터를 보내줄 때, Last-Modified 를 헤더에 넣어서 보낸다.
캐시의 시간이 초과해 서버에 데이터를 다시 요청할 때, if-modified-since 날짜와 서버 요청데이터의 Last-Modified 날짜를 비교해서 일치하면
(304 Not Modified + HTTP 헤더정보) 만 받아와서 캐시의 정보를 갱신하고, 클라이언트는 기존에 가지고 있던 캐시를 재사용한다.

6-5-2 If-None-Match: ETag

데이터를 수정해서 날짜가 다르지만, 데이터 결과가 똑같은 경우
캐시 제어 로직을 서버에서 완전히 관리하고 싶은 경우

서버가 요청받은 데이터를 보낼 때, 캐시용 데이터에 임의의 고유한 버전 이름을 달아둠
서버 데이터가 변경되면 서버가 이름을 바꾸어서 변경함(Hash를 다시 생성)

진짜 단순하게 ETag만 서버에 보내서 같으면 유지, 다르면 다시 받기

6-5-3 캐시 제어 헤드

Cache-Control: max-age(캐시 유효 시간, 초 단위)
Cache-Control: no-cache (데이터는 캐시해도 되지만, 위의 두 가지 방법 중 하나로 항상 원(origin) 서버에 검증하고 사용)
Cache-Control: no-store (데이터에 민감한 정보가 있으므로 저장하면 안됨)

6-5-4 프록시 캐시

Cache-Control: public -> 응답이 public 캐시에 저장되어도 됨
Cache-Control: private -> 응답이 해당 사용자만을 위한 것임, private 캐시에 저장해야 함(기본값)

6-5-6 캐시 무효화

Cache-Control: no-cache : 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용
원 서버와의 연결이 끊겨 접근할 수 없는 경우, 설정에 따라서 캐시를 반환할 수도 있음
Cache-Control: no-store : 데이터에 민감한 정보가 있으므로 저장하면 안됨
(메모리에서 사용하고 최대한 빨리 삭제)
Cache-Control: must-revalidate : 캐시 만료후 최초 조회시 원 서버에 검증해야함, 원 서버 접근 실패시 반드시 오류가 발생해야함 -> 504(Gateway Timeout), must-revalidate는 캐시 유효 시간이라면 캐시를 사용함
Pragma: no-cache : HTTP 1.0 하위 호환

7. HTTP 버전별 특징

HTTP/0.9
사용 가능한 메서드는 GET이 유일 / HTTP 헤더가 없기 때문에 전송은 HTML 문서만 가능
응답은 오로지 파일 내용 자체로 구성( 상태 혹은 오류 코드가 존재하지 않았음)
HTTP/1.0
HTTP 헤더 개념 도입 / HTML 파일들 외에 다른 문서들을 전송하는 기능 추가(Content-type)
/ 상태 코드 주입/ POST 메서드 추가
단일 연결 당 하나의 요청과 응답만 처리가능
HTTP/1.1 - 표준 프로토콜
첫 번째 표준 버전이며, 메서드에 OPTION, PUT, DELETE, TRACE가 추가되었음
Keep-Alive 기능(디폴트)을 도입하여 Keep-Alive 유지시간동안 단일 연결에서 여러 요청과 응답을 처리할 수 있습니다. 비연결성을 위반한 것이라고 할 수 있지만 많은 횟수의 요청을 처리할 때 발생하는 오버헤드를 줄이는 장점이 있다.
여러 개의 요청을 한 번에 전송하고 응답을 순차적으로 받는 기법인
파이프라이닝(Pipelining)을 지원하여 여러 요청을 병렬로 처리할 수 있습니다.
HTTP/2.0
바이너리 포맷으로 인코딩된 Message가 프레임에 담겨 전송됨.
이진 프레이밍(Binary Framing) 방식을 사용하여 헤더 압축과 데이터 스트림 분할을 지원합니다.
다중화(Multiplexing)를 지원하여 단일 연결에서 동시에 여러 요청과 응답을 처리할 수 있습니다.
서버 푸시(Server Push) 기능을 도입하여 서버가 클라이언트에게 추가 리소스를 미리 전송할 수 있습니다.
헤더 압축, 스트림 우선순위, 서버 힌트 등의 기능을 제공하여 네트워크 성능을 향상시킵니다.
HTTP/3.0
HTTP 3.0 버전은 UDP를 기반으로 하는 QUIC 프로토콜을 사용
QUIC 프로토콜 : TCP가 가지는 문제점을 해결하고자 구글이 개발한 UDP 기반의 프로토콜
다중화, 암호화, 오류 복구 등의 기능을 제공합니다.

8. CDN, ACL, Proxy, SSL

8-1 CDN

컨텐츠 전송 네트워크로 데이터 사용량이 많은 애플리케이션의 웹 페이지 로드 속도를 높이는 상호 연결된 서버 네트워크이다.
웹 사이트를 방문할 때 해당 웹 사이트 서버의 데이터가 인터넷을 통해 사용자의 컴퓨터에 도달하게 된다. 이때 사용자가 해당 서버에서 멀리 떨어져 있는 경우, 동영상이나 이미지와 같은 대용량 파일을 로드할 때 많은 시간이 걸리게 된다. 사용자와 가까운 거리에 CDN 서버를 두어 웹 사이트 콘텐츠를 저장해놓으면 사용자는 훨씬 빠른 속도로 콘텐츠를 로드할 수 있다. CDN은 캐싱과 로드 밸런싱을 통해 콘텐츠를 최적의 서버로 배분하고, 요청은 오리지널 서버에 하더라도, 이미지 등의 데이터는 가까운 CDN서버에서 가지고 올 수 있다.
대표적으로 aws에서 제공하는 CDN서비스인 CloudFront 서비스가 있다

8-2 ACL

허가되지 않은 이용자가 라우터나 네트워크에 접근하려고 하는 것 또는 특정 서비스의 이용을 차단하고 출발지 주소, 목적지 주소, 포트 번호, 프로토콜로 특정 패킷을 필터링할 수 있고 허가 및 거부할 수 있습니다.

8-3 Proxy 서버

클라이언트가 서버에 간접적으로 접근할 수 있게 해주는 중간 서버이다. 프록시서버가 클라이언트로부터 요청을 받고, 그 요청을 서버로 전달한다.
웹서버인 엔진엑스는 프록시서버 용도로도 사용한다.
포워드 프록시 : 일반적인 프록시 개념. 캐시, 접근제어, 보안, 사용률 파악의 장점이 있다.
리버스 프록시 : 받은 요청을 여러 서버들 중 하나로 전달하는 부하분산의 역할을 한다.

8-4 SSL

HTTP에 보안을 더해 HTTPS로 만들어주는 프로토콜. SSL의 향상된 버전이 TLS이지만 보편적으로 SSL 이라는 용어로 같이쓰임

8-4-1 인증서 등록방식

연결되는 서버가 신뢰할 수 있는 서버라는 것을 증명하는 인증서

ssh-keygen으로 비대칭 키 생성
server public, server private 이렇게 2개의 key가 생성됨
도메인이름, 요청하는 사람의 정보, public key을 가지고 인증기관에 가서 인증서명요청
인증기관은 자신이 가지고 있는 private key 키로 암호화하여 인증서 발급
개발자가 인증서를 다운로드
다운로드 받은 인증서를 서버에 올린다
SSL 서버 통신설정

8-4-2 인증방식

브라우저에 인증기관의 공개키가 내장되어 있음
클라이언트가 서버에 인증서를 요청하고 받음
받은 인증서를 클라이언트가 CA의 공개키로 풀어본다
도메인을 확인하고 일치하면 인증서 안에 적혀있는 서버의 public key를 가지고 온다
대칭키를 만든다
서버의 public key로 대칭키를 암호화
암호화 된 값을 서버에 보낸다
서버는 자신이 가진 private key로 복호화
양쪽 모두 대칭키를 가지게 됨
무료 인증기관 : Let's encrypt

9. HOST

HOST는 네트워크에 연결된 컴퓨터를 의미한다. 해당 PC가 네트워크 인프라를 이루는 장비(라우터 등)인 경우 switch라 하고, 해당 인프라를 사용하는 일반 user(클라이언트, 서버, peer) PC의 경우 end-point라고 생각하면 된다.
컴퓨터가 어떤 역할을 하느냐에 따라 나눈 분류인 것이다.
아주 간단히 요약하면 switch는 네트워크 인프라, end-point는 인프라를 사용하는 유저다.
스위치는 패킷이 교차로(라우터)에서 어떤 방향으로 갈 것인지 매트릭 값(비용)을 고려하려 경로를 결정한다.

10. L2

엔드포인트와 물리적으로 연결되는 스위치로 각각을 port라고 부른다. 이 그림은 24port hub이다.
pc와 스위치의 연결이 정상이라면 Link-up, 정상이 아니라면 Link-down이라고 한다.
L2 Access switch와 다른 라우터들과 연결되는 등 상위계층과 연결되는 선은 uplink라고 한다.
L2 distribution switch : L2 Access switch들의 연결이 모이는 상위 스위치
header에 출발지와 도착지의 주소가 있는데 도착지의 mac주소를 모두 1로 설정하면 브로드캐스트로 설정되어 모든 장치에 전송된다. 브로드캐스트가 완료되기 전까지 장치들은 통신을 못하게 된다.
LAN이라는 물리적 네트워크 위에 WAN이라는 논리적 네트워크(Internet)가 존재한다.
하드웨어(물리적 존재)를 소프트웨어 기술(논리적 존재)로 변환하는 것을 가상화 기술이라고 한다.(virtual)
하드웨어인 cpu는 소프트웨어 용어로 머신이라고 한다.

11. L3

IPv4 , IPv6 로 32bit(8bit * 4) 로 구성된다. 8비트씩 자르고 .을 찍어서 구분한다. 각각의 숫자는 0~255사이의 숫자로 이루어진다. IP는 네트워크 아이디와 호스트 아이디로 이루어져있다. Network ID는 서울시 강남구 역삼동 같은 큰 틀, Host ID는 번지라고 생각하면 된다.
L3 IP 패킷 : 패킷은 네트워크에서 전송되는 데이터의 단위로 헤더(머리) + 페이로드(내용/데이터) + 트레일러(꼬리)로 구성된다. 최대크기는 MTU(1500bytes)

가장 큰 틀이 L2 Frame단위, 그 안에 L3 IP 패킷, 그 안에 L4 .. 이렇게 캡슐화

패킷 생성, 전달과정
데이터를 패킷으로 만듬 - L4, L3를 거치면서 헤더가 붙는다. - L2 ACCESS SWICH - 게이트웨이(택배기사) - 라우팅(물류센터 등) - host - 받는 프로세스(받는사람 이름, port번호)

Socket에서는 stream에 전송할 데이터를 write한다. 운영체제 입장에서 프로세스가 데이터를 write하고 언제 끝낼 지 알 수 없으므로 stream을 통해 넘어올 데이터는 크기를 정확히 알 수 없는 데이터이다. segment(MSS) 의 최대 크기는 1460byte, MTU는 1500bytes이라서 넘어온 데이터를 받을 수 없으므로 stream이라는 연속적인 데이터 MSS사이즈에 맞게 분할하고 MTU사이즈에 맞추어 인터넷에서 사용한다.
- Socket - Stream
- Tcp - segment - MSS
- Ip - packet - MTU

게이트웨이 : 한 네트워크(segment)에서 다른 네트워크로 이동하기 위하여 거쳐야 하는 지점이다. 기계, 장비가 아니라 인터넷 방향으로 나갈 때 찾아갸야할 IP 주소를 말한다.
이 그림에서 공유기와 인터넷 제공 회사의 라우터는 이전의 단계에서 다음 단계로 넘어 갈 때의 게이트웨이 역할을 담당합니다. 이 때, 거치는 게이트웨이의 수를 홉 수(hop count)라고 한다. (라우터에서 다른 라우터를 지날때의 단위)
라우터(=물류센터) : 라우터는 OSI7계층 중 3 계층( 네트워크 계층) 에 속하는 장비이다. (= L3 switch - 논란의 여지가 있음)
- 경로 설정 : 내부 네트워크와 외부 네트워크를 연결해주는 장치로 데이터 패킷이 목적지까지 갈 수 있는 길을 검사하고 어떤 경로로 전송하는 것이 가장 효율적일지 결정한다
- 스위칭 : 경로가 결정되면 해당 경로로 데이터 패킷을 넘겨준다.

12. TCP/IP 송수신구조

서버에 연결된 buffer (개발자가 버퍼 크기를 정한다)
소켓에 연결된 buffer

송신

일정 크기의 데이터를 복사해서 서버 buffer에 올린다.
서버 버퍼에 올라간 데이터를 또 복사해서 소켓 버퍼에 올린다.
tcp로 보낼때 데이터가 분해된다(segment가 된다)
ip계층에서 segment를 포장한다. (packet)
Frame단위로 변환(트럭) 한 방에 목적지로 가는 것이 아니기 때문에 Frame는 계속 바뀐다

수신

Frame단위로 받은 데이터를 받고 packet이 나온다(내용물이 들어간 상자)
상자(packet)은 버리고 내용물을 꺼낸다(segment)
소켓으로 입출력한다. (소켓버퍼로 데이터를 올린다)
소켓버퍼의 데이터를 서버퍼버로 올린다.(프로세스로 올리면서 소켓버퍼를 비운다)
데이터를 몇 번까지 받았는지 ack번호 + 여유공간(window size)을 송신측에 보낸다

발생할 수 있는 장애

Loss
retransmission + ack duplication
out of order
zero window (end-point단계 문제)

13 broadcast IP주소

host id가 모두 1이면 브로드캐스트 ip주소로 사용된다

14 TTL과 단편화

TTL : 패킷이 라우터에서 다른 라우터로 이동할 때 숫자가 감소하는데 정해진 숫자가 모두 감소해서 0이되면 해당 패킷이 도착한 라우터에서 패킷을 버리고 OS가 삭제한다.
단편화 : 패킷 하나의 크기는 일반적으로 1500byte이다. 하지만 어떤 라우터에서 받을 수 있는 MTU의 크기가 1500byte보다 작을 수 있다. 이때 하나의 패킷을 쪼개는 단편화가 일어난다. 쪼개진 2개 이상의 패킷은 일반적으로 패킷을 받는 서버에서 조립한다. (VPN을 사용하는 경우 단편화가 일어날 가능성이 높아진다)

15 인터넷 설정 자동화를 위한 DHCP

IP주소
Subnet mask
Gateway IP주소
DNS 주소
1~3까지는 L3에 관한 설정

IP, Gateway IP주소, Subnet mask 모두 일반적으로 자동으로 주소 받기를 사용한다. 이때 자동화를 위해 사용하는 것이 DHCP이다.
DHCP Server는 broadcast domain에 묶여서 해당 LAN영역에서 host가 요청한 인터넷 설정에 필요한 작업을 자동으로 세팅해준다.
- pc의 전원이 켜지면 브로드캐스트 패킷이 나간다.(DHCP 서버가 있는지 찾기위해).
- 게이트웨이 안에 있는 DHCP서버가 응답한다.
- 이전에 IP주소 등을 할당받은 적이 있다면 계속 사용해도 되는지 확인하고, 받은 적이 없다면 DHCP서버가 새로운 주소를 할당한다
broadcast domain에 묶였기 때문에 gateway의 네트워크 주소를 넘어서 외부 네트워크와 통신하지 않는다. 즉 broadcast는 gateway 안 쪽에 존재한다.

16 ARP

IP주소를 사용해서 MAC주소를 알아내려고 할 때 사용한다. (GateWay의 MAC주소를 알아내려고 할 때가 대표적이다.) DHCP가 게이트웨이의 MAC주소를 알려주지는 않는다.
PC가 인터넷에 접속하려면 게이트웨이의 mac주소를 반드시 알아야한다.
PC는 게이트웨이의 mac주소를 파악하기 위해 ARP Request를 보낸다. 브로드캐스트로 게이트웨이IP주소를 사용하는 것이 어떤 것인지 찾는다. (DHCP서버를 찾는 과정과 유사하다.)
게이트웨이는 응답하면서 자신의 mac주소도 같이 알려준다.
pc가 인터넷에 접속할 때 패킷이 나간다. IP패킷에서 출발지는 pc의 아이피, 도착지는 인터넷의 IP / L2 프레임 단위에서 출발지는 pc의 mac주소, 도착지는 게이트웨이 mac주소
(인터넷에 접속할 때, 목적지의 mac주소는 게이트웨이로 잡힌다.)

17 Ping, RTT

Ping은 특정 host에 대한 Round Trip Time를 측정할 목적으로 사용된다.
RTT는 인터넷 상에서 송신지부터 목적지까지 패킷이 왕복하는데 걸리는 시간을 말한다.
ICMP 프로토콜을 사용한다.
-참고
https://backendcode.tistory.com/166
https://code-lab1.tistory.com/261
Gateway(게이트웨이)란 ? Router(라우터)란? 각 개념과 차이점에 대해 알아보자.

Seung jun Cha

이전 포스트

예외처리, Converter, Fommater

다음 포스트