HTTP

모든 것은 HTTP 기반 위에서 동작한다.
html 이미지 영상 파일 뿐만 아니라 앱과 서버가 통신할때와 서버와 서버끼리 통신할때도 HTTP프로토콜 위에서 
데이터를 주고 받는다.
특히 백엔드 개발자는 SpringMVC나 JSP PHP, 파이썬 장고 루비온레일즈같은 웹 기술이나 웹프레임워크를 사용
하게 됨 이런 웹 기술들이 모두 HTTP 기반으로 구현되어있음.
 
인터넷 네트워크
1. 인터넷 통신
컴퓨터 둘이 붙어있으면 단순히 케이블을 연결해서 사용이 가능하다 하지만 현대에는 컴퓨터간의 거리가 멀리떨어져
있기 때문에 통신의 어려움이 존재한다. 이것을 해결하기 위해 나온것이 인터넷 통신 이다. 멀리있는 컴퓨터와의
통신은 해저케이블이 될수도있고 인공위성을 통해 내려올 수도 있다. 수많은 중간 노드라는 서버를 거쳐서 메시지가
안전하게 넘어가야한다. 어떠한 규칙으로 안전하게 거쳐서 넘어가는지는 IP를 통해 알 수 있다.
2. IP(Internet Protocol) (IP주소를 부여하고 찾아가는 방식을 IP라 부른다.)
복잡한 인터넷망에서 다른 컴퓨터로 메시지를 보낼때는 규칙이 필요하다. 그것이 IP 주소이다.
IP 즉, 인터넷 프로토콜의 역할은
지정한 IP주소(IP Address)에 데이터를 전달한다. 패킷이라는 통신 단위로 데이터를 전달한다.
IP 패킷 정보에는 내 아이피와 메시지를 받을 상대 아이피와 전송할 데이터 즉 메시지를 넣어줄 수 있다.
인터넷망에 IP패킷을 주게되면 이러한 패킷을 노드끼리 받아서 전달전달전달을 통해 최종으로 전달이 되게된다.
이러한과정이 가능한 이유는 IP통신 프로토콜의 통신규약 덕분에 가능하다.
받은 서버는 잘 전달이 되었다고 보내줄 때 다시 노드들을 왕복해서 다시 나에게 전달이 된다.
인터넷망이 워낙 복잡하기에 내가 전달할때 이용한 노드들을 다시 받을때는 이용안하고 다른 노드들을 통해
올 수도 있다. 그런데 이러한 IP프로토콜의 방식에는 한계가 존재한다.
( IP주소를 부여하고 찾아가고 , IP패킷에 담아주는 이러한 방식의 한계 )
 
IP 프로토콜의 한계
1. 비연결성
패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
( 클라이언트는 대상 서버가 패킷을 받을 수 있는 상태인지 아닌지 모른다.  )
2. 비신뢰성
중간에 패킷이 사라지면?
노드도 결국 서버이다. 패킷을 보낼때 중간 노드가 꺼져버리거나 사라진 경우에는 내가 보내는 패킷이 유실될 수 있다.
( 예를 들면 광케이블이 망가지는 경우 패킷의 유실이 발생할 우려가 존재한다. )
패킷이 순서대로 안오면? ( 패킷 여러개 보냈을때 순서? )
패킷의 들어가는 메시지가 너무 많아지면 한번에 보내기가 부담스러워져 패킷을 끊어서 보내게 된다. 보통 (1500바이트)
패킷들은 중간에 다른 노드를 탈 수가 있다. 이러한 과정 때문에 보내는 순서가 보장이 되지 않는다. 의도가 전혀 달라짐.
3. 프로그램 구분
같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이면?
온라인 게임을 통해 같은 IP가 중복되는 경우? 문제? 이런걸 구분 어떻게 할 것인가?
 
이러한 문제들을 해결해 주기 위해 나온 방법이 TCP프로토콜이다.
3. TCP, UDP
인터넷 프로토콜 스택의 4계층
1. 애플리케이션 - HTTP, FTP ( 젤위 )
2. 전송 계층 - TCP, UDP
3. 인터넷 계층 - IP
4. 네트워크 인터페이스 계층
이곳의 IP계층에 TCP를 계층을 올려 보완을 해준다.
 
프로토콜 계층
애플리케이션 -> 웹 브라우저, 네트워크 게임, 채팅 프로그램 등등 ( SOCKET 라이브러리 )
OS -> TCP, UDP, IP(Internet Protocol)
네트워크 인터페이스 -> LAN드라이버 LAN장비 -->> LAN카드 
계층을 통해 전달이 되는 과정
1. 프로그램이 Hello, world 메시지 생성 후 애플리케이션 계층에 SOCKET라이브러리를 통해 OS계층에 전달
2. OS 계층의 TCP가 HelloWorld라는 메시지에 TCP정보를 씌운다.
3. TCP 밑에 IP계층에 IP와 관련된 데이터를 씌운다. 이렇게해서 IP패킷이 생성이된다.
4. IP패킷은 네트워크 인터페이스를 통해서 LAN카드를 통해서 나갈때 이더넷 프레임이 씌워져서 나가게된다.
즉 , 이러한 과정을 통해 내가 정보를 전달할 수 있게 된다.
 
IP 패킷 안에는 TCP의 정보가 들어감
TCP의 정보는 출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보...등이 들어간다.
IP만으로는 해결이 안돼는 정보들을 입력해줌으로써 IP의 문제를 해결해준다.
 
TCP특징
전송 제어 프로토콜(Transmission Control Protocol)
1. 연결지향 - TCP 3 way handshake(가상 연결)
컴퓨터간의 연결여부를 확인 후 연결을 해주고 패킷을 보내주는 방식(연결 지향)
클라이언트가 서버로 데이터를 전송할때 SYN이라는 접속 요청 메시지를 보내고 서버의 컴퓨터가 켜져있으면
SYN(접속 요청) + ACK(접속 수락)를 보내게 된다 다시 왔을때는 클라이언트는 ACK(요청 수락)을 보내며 통신이
이루어진다. ( 이렇게 3번 주고 받기때문에 3 way handshake라고 부른다. ) 응답이 없으면 안보내게 된다.
SYN : 접속 요청
ACK : 요청 수락
2. 데이터 전달 보증
패킷이 중간에 누락이 되면 메시지를 못받았다는걸 알 수가있게된다.
3. 순서 보장
순서를 보장해줌.
신뢰할 수 있는 프로토콜 / 현재는 대부분 TCP를 사용한다.
순서가 잘못된 곳부터 다시 보내달라고 요청을 하게됨.
TCP에는 전송정보 및 순서정보도 포함이 되어있기 때문에 순서를 알 수 있게됨.
UDP 특징
사용자 데이터그램 프로토콜(User Datagram Protocol)
1 하얀 도화지에 비유(기능이 거의 없음)
2 연결지향 - TCP 3 way handshake X
3 데이터 전달 보증 X
4 순서 보장 X
5 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름
정리
IP와 거의 같다. +PORT+체크섬 정도만 추가
애플리케이션에서 추가 작업 필요
체크섬 : 메시지에 대해 맞는지 검증 데이터 정도가 추가가 되어있음.
TCP의 최적화를 위해 사용을 하는 것은 UDP이다.
4. PORT ( 영어 뜻은 배가 도착하는 항구라는 뜻임 )
하나의 아이피에서 여러가지 애플리케이션의 요청을 하면 여러가지 패킷이 들어오게됨. 이러한 애플리케이션의
구별이 어렵기 때문에 나온 방법이다. ex) 게임용인지, 음악용인지 등등 
한번에 둘 이상 연결해야 할때 사용한다.
게임과 화상통화 웹 브라우저 요청등 한번에 요청을 하게 되면 패킷의 구분을 위해 나온 방법이다.
같은 아이피 내에서 프로세스를 구분하는것은 포트번호이다.
TCP/IP 즉, IP안에 TCP안에 클라이언트의 PORT또한 같이 보내게 된다. 그러면 상대방은 PORT를 보고 
자신의 PORT또한 같이 보내주면서 통신이 된다. PORT는 게임 화상통화 및 웹 브라우저 등등이 다 다르다.
PORT는 0 ~ 65535 까지 할당이 가능하다. 0 ~ 1023은 잘 알려진 포트라 사용하지 않는 것이 좋다.
HTTP : 80 포트이다.
HTTPS : 443 포트이다.
5. DNS(Domain Name System) 도메인 네임 시스템 // 서버임 이거
기존에는 IP를 통해 통신을 해봤는데 이 아이피를 기억하기가 어렵다. 또 아이피는 변경 가능성이 있음.
이렇게 되면 변경된 아이피를 알 방법이 없어진다. 항상 보내던 곳에만 보내며 기억을 했기에 문제가 생김.
이러한 문제를 해결할 수 있는 DNS가 나왔음.( 중간의 전화번호부 같은 서버를 제공을 해준다.)
DNS서버에 도메인을 등록할 수 있음. 도메인은 google.com같은 이름으로 등록이 가능하다!
클라이언트가 도메인을 통해 접근이 가능해짐. 도메인 서버 즉 DNS서버에 도메인 명을 통해 해당 도메인의
IP주소를 요청하게됨. DNS서버가 IP주소를 응답을 해줌. 그리고 그 IP주소를 통해 접속을 하게 된다.
IP를 변경하게 되면 DNS서버의 IP주소를 바꾸고 본인의 IP주소를 바꾸게 됨. 이러한 방식으로 문제가 해결됨.
(변경 및 기억의 문제를 해결함 ) 마치 전화번호 부 마냥 해결
 
URI와 웹 브라우저 요청 흐름
URI(Uniform Resource Identifier) ( 리소스를 식별하는 통합된 방법? 이런 뜻임 )
URI 리소스를 식별한다. 큰범위 안에 URL , URN이 들어가있다.
URL(Resource Locator) , URN(Resource Name) 이름
Uniform : 리소스 식별하는 통일된 방식
Resource : 자원, URI로 식별할 수 있는 모든 것(제한 없음)
Identifier : 다른 항목과 구분하는데 필요한 정보
 
URL - Locator : 리소스가 있는 위치를 지정
URN - Name : 리소스에 이름을 부여
위치는 변할 수 있지만, 이름은 변하지 않는다.
 
웹 브라우저 요청 흐름
[userinfo@] : URL에 사용자정보를 포함해서 인증 / 거의 사용하지 않음
host : 호스트명 / 도메인 명이나 IP주소를 직접 사용이 가능함.
port : 포트는 생략이 가능하며 http는 80 https는 443 ( 포트는 어차피 단순히 구분을 위한 UDP의 기능임 )
path : 리소스 경로(path), 계층적 구조
 
URL에 경로를 입력을 하면 웹 브라우저는 DNS서버를 조회 후 IP주소를 받아온다. port를 생략 하면
http는 80 , https는 443으로 port가 입력이 된다. ip주소와 포트정보를 찾아낸다.
HTTP요청 메시지를 생성한다. 
웹 브라우저가 HTTP 메시지 생성 소켓 라이브러리를 통해 OS에 TCP/IP계층에 전달을 한다. 
(이 과정은 연결을 시키는 과정이다. TCP 3way handshake의 가상연결을 통해 확인 하는 과정이다.)
TCP/IP 로 구글 서버 연결(IP, PORT) 후 데이터 전달
TCP/IP 패킷 생성, HTTP 메시지 포함 LAN을 통해 인터넷 -> 서버로 간다.
인터넷망에 던지면 수많은 노드를통해 전달이 되게 된다.
요청이 가면 TCP/IP패킷을 까고 HTTP메시지를 뽑게된다. HTTP메시지를 해석을 한 후 서버에서 데이터를 찾아
HTTP 응답 메시지를 생성해서 보내준다.
Content-Type: text/html;charset=UTF-8 ==> 응답하는 데이터 형식의 컨테트타입을 알려주는것이다.
응답하는 형태는 text/html형식이구나. 언어는 UTF-8로 셋이 되어있구나. 를 알려준다.
Content-Length : 3423 ==> 실제 컨테트타입의 html 길이를 알려주는 문장이다.
 
구글서버마저 똑같은 응답 패킷을 만들고 그 위에 TCP/IP패킷을 씌워서 보내게 된다. 이러한 방식으로 현재는
모든 웹이 통신을 한다.
 
응답이온 html 데이터를 까봐서 html렌더링을 한 후 결과을 보게된다. 이러한 전체적인 동작이 있다.
 
http(프로토콜임)는 tcp/ip기반으로 만들어진 프로토콜이다.
즉, TCP기반으로 HTTP프로토콜이 사용이 된다. HTTP는 TCP/IP스택에 의존하여 사용한다.
따라서 HTTP는 TCP의 기능을 사용하지만, 정의된 프로토콜 자체가 다름으로 같게 보면 안된다.
하지만 HTTP가 TCP를 사용하여 데이터를 전송하기 때문에, HTTP는 TCP의 여러 특성
(연결 지향성, 신뢰성, 흐름 제어 등) 을 갖게 된다.
HTTP는 TCP/IP 위에서 동작하며, HTTP 요청과 응답은 TCP/IP를 통해 전송됩니다.
 
HTTP의 중요한 특징 중 하나로는 Stateless(무상태) 프로토콜을 지향한다는 점이다.
이 Stateless를 알기 전에 반대되는 Stateful(상태유지)를 알아야 한다.
Stateful : 상태유지 프로토콜 방식

Stateful은 서버가 클라이언트의 상태를 보존해주는 프로토콜 방식이다.
Stateful(상태유지) 같은 경우에는 연결이 유지가 된다. 예시로 들면
웹사이트의 로그인 기능같은 다른 페이지로 이동했을 경우에도 로그인이 유지가된다.
이건 계속 연결이 되어있는 경우이다. 즉, 상태유지라고 생각하면 된다. 상태유지가 되야지
물건을 구매했을 때 해당 로그인된 정보를 토대로 결제를 하기 때문이다.
즉 서버에서 회원의 정보를 가지고 상태를 유지하기 때문에 지속적인 연결이 되어있는 상태이다.
Stateless : 무상태 프로토콜 방식
Stateless는 서버가 클라이언트의 상태를 보존하지 않는 프로토콜 방식이다.
즉, 연결을 지속적으로 하지 않고 필요한 데이터만 주고 연결을 끊어버린다는 의미이다.
반면에 Stateless(무상태)의 경우에는 데이터를 회원이 가지고 있다가 보내는 방식이다. 즉, 로그인 같은
정보를 클라이언트의 브라우저의 쿠키를 통해 저장을 해놓는다던지 방식을 이용해 클라이언트가 즉각적으로
필요할때 자기 정보를 같이 넘김으로써 서버는 받고 요청에 필요한 데이터만 응답하고 연결을 끊으면 
해당 서버는 다른 요청에도 빠르게 받을 수 있으며 상태를 가지고 있지 않기때문에 유연하게 다른 서버에 요청을
보내도 받을 수 있게 된다. 정리하면 서버가 클라이언트의 상태를 보존하지 않는다는 말이 이런말이다.
이렇게 Stateless(무상태)의 장점은 갑자기 클라이언트의 요청이 증가해도 서버를 대거
투입이 가능하며 응답서버에 대한 요청을 다른 서버에서도 똑같이 받을 수 있어서 서버의
증설이 쉽고 스케일 아웃이라고 수평 확장에 매우 유리한 조건이 된다.
 
하지만 Stateless에도 한계가 존재한다.
모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다.
단순한 소개페이지일경우에는 상태를 유지할 필요가 없기에 무상태로 설계하기가 쉬움
상태를 유지해야하는경우 => 로그인 서버에서 유지를 해줘야한다.
일반적으로는 브라우저의 쿠키와 서버의 세션을 잘 조합해서 상태를 유지하는 기능을 사용하는게 가능하다.
이런식으로 어쩔수없이 상태유지가 필요해지는 경우가있다. 하지만 상태유지는 최소한으로 사용을 해줘야한다.
(꼭 필요한 경우에만 어쩔수없이 사용해야한다.)
Stateless에는 단점이 하나 더 존재한다.
데이터를 너무 많이 보낸다는 점이다.
클라이언트가 데이터를 보낼때 앞에서 봤듯이 Stateless는 보내고 연결을 끊는 방식이라 앞에서 내가 선택한
정보들을 서버에서 저장을 해주지않음으로 지속적으로 클라이언트가 가지고 있다가 보내기때문에 중복되는
데이터또한 많이 존재하게 된다.( 음 이부분은 설명이 좀 어려운거같군.. )
 
비연결성
TCP/IP 같은 경우에는 기본적으로 연결을 유지해준다. TCP/IP 소켓을 연결 한 후 클라이언트가 서버에 요청을
하면 응답이 온다.( 이 경우에는 데이터를 보내줬음에도 계속 연결이 되어있다. ) 이런게 지속이 되면 서버에
자원낭비가 매우 심해진다. 이런걸 보완하기 위해 나온 비연결성이란 개념이 있다.
비연결성은 요청을 하고 응답이 오면 연결을 끊어버린다. 서버가 유지하는 자원을 최소화로 할 수 있다.
서버가 유지해야할 자원은 요청이 오면 그것만 응답을 보내줘 연결을 끊어버리기때문에 매우 좋은 장점이있다.
 
HTTP같은 경우에는 기본적으로 연결을 유지하지 않는 모델이다.
일반적으로 초 단위의 이하의 빠른 속도로 응답
1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음.
예) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다.
서버 자원을 매우 효율적으로 사용할 수 있음.
 
비연결성의 단점
TCP/IP연결을 새로 맺어야 함 - 3 way Handshake 시간 추가가 된다.
웹 브라우저로 사이트를 요청하면 HTML뿐만 아니라 자바스크립트, css, 추가 이미지 등등 수 많은 자원이 함께 다운된다.
이 자원들을 하나하나 받을때마다 연결하고 끊기에는 시간도 오래걸리고 비효율적인거 같다.
현재의 HTTP는 지속 연결(Persistent Connections)로 문제 해결
HTTP/2, HTTP3에서는 훨씬 최적화가 되어있음.
 
지속연결 같은 경우에는 연결 후 HTML요청 응답 자바스크립트 요청 응답 이미지 요청 응답 후 종료를 하는 방식을 이용.
요청하고 다 받고 뒤에 종료가 되는 방식이다.
 
HTTP 메시지
HTTP는 (HyperText Transfer Protocol)
문서간의 링크를 통해 연결할 수 있는 html이라는 뜻이다. 과거에는 이랬지만 현재에는 모든 곳의 HTTP가 들어간다
즉, 과거에는 HTTP메시지에 담는게 한정되었었는데 현재에는 많은 것을 담아 보내게된다.
HTML, TEXT, image, 음성, 영상, 파일 등등 json, xml, (api) 등등, 거의 모든 형태의 데이터 전송이 가능
서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용한다.
 
HTTP의 특징은 첫번째로 클라이언트와 서버 구조로 되어있음.
Request Response 구조
클라이언트는 서버에 요청을 보내고, 응답을 대기
서버가 요청에 대한 결과를 만들어서 응답
( 이런식으로 구조를 나눔으로써 서로의 역할을 제대로 명시가 가능해진다. )
 
HTTP에는( 요청과 응답 메시지 )
start-line(시작 라인), header 헤더, empty line 공백 라인(CRLF), message body(메시지 바디) 영역이 존재한다.
HTTP(요청 메시지)
1. 시작 라인(요청 메시지)
start-line(시작 라인)은 크게 request-line, status-line으로 되어있음. ( 요청 메시지는 request-line이라함 )
* request-line - method(get,post등등) / request-target(요청하는 대상) / HTTP 버전이 존재한다.
HTTP 메서드
종류 : GET, POST, PUT, DELETE
서버가 수행해야 할 동작 지정
요청 대상
absolute-path라고 절대경로로 시작을하게됨. ex) GET/search?q=hello&hi=ko HTTP/1.1
절대경로 = "/"로 시작하는 경로
버전정보에는 HTTP 버전이 들어가게된다.
 
HTTP(응답 메시지)
시작 라인
start-line에 request-line, status-line중 status-line이 응답 메시지때 사용을 하게된다.
status-line에는 = HTTP-version / status-code / reason-pharse CRLF
HTTP 버전
HTTP 상태 코드 : 요청 성공, 실패를 나타냄
200 : 성공
400 : 클라이언트 요청 오류
500 : 서버 내부 오류
OK => 이유 문구 : 사람이 이해할 수 있는 짧은 상태 코드 설명 글(상태 코드를 나타내는 짧은 글)

HTTP 헤더( 요청과 응답 ) 두개의 헤더가 생긴게 다름.
header-field =>> field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용)
요청 헤더
GET/search?q=hello&hi=ko HTTP/1.1
Host: www.google.com  이런식으로 작성을 함.
응답 헤더
Content-Type: text/html; charset=UTF-8
Content-Length: 3423 등등
HTTP 헤더 같은 경우에는
HTTP 전송에 필요한 모든 부가정보를 다 담고있다.
예) 메시지 바디의 정보, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 서버 앱 정보,
캐시 관리 정보 등등... 메시지 바디가 html로 되어있는가 아닌가 알려주는 부가정보임.
표준 헤더가 너무 많음, 필요시 임의의 헤더 추가 가능, helloworld: hihi 이런것도 가능함.
 
HTTP 메시지 바디
실제 전송할 데이터가 담긴다.
HTML문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송이 가능하다.
압축해서 보내면 압축된 내용이 들어가게 된다.
 
HTTP 메서드 종류
GET : 리소스 조회
POST : 요청 데이터 처리, 주로 등록에 사용( 데이터를 보내서 뭘 할때 주로 사용 )
PUT : 리소스를 대체, 해당 리소스가 없으면 생성 ( 말그대로 덮어버린다는 의미? )
PATCH : 리소스 부분 변경 ( 특정 필드 몇개를 바꿀때 사용 update )
DELETE : 리소스 삭제
// 그 외
HEAD : GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
 
GET
리소스 조회 , 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)을 통해서 전달
메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음.
POST
요청 데이터 처리
메시지 바디를 통해 서버로 요청 데이터 전달 / 서버는 요청 데이터를 처리
메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.
주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용
PUT
리소스를 완전히 대체
리소스가 있으면 대체
리소스가 없으면 생성
쉽게 이야기해서 덮어버림
중요! 클라이언트가 리소스를 식별
클라이언트가 리소스 위치를 알고 URI 지정
PATCH
리소스 부분 변경
DELETE
리소스 제거
 
HTTP 메서드의 속성
안전(Safe Methods)
호출해도 리소스를 변경하지 않는다.
멱등(Idempotent Methods)
한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다 라는 의미임 멱등은
캐시가능(Cacheable Methods)
GET, HEAD, POST, PATCH 캐시가능
실제로는 GET, HEAD정도만 캐시로 사용
POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음.
캐시 : 웹브라우저가 받아온 이미지를 저장하고있을 수 있는가
 
HTTP 메서드 활용
클라이언트에서 서버로 데이터 전송
1. 쿼리 파라미터를 통한 데이터 전송
GET
주로 정렬 필터(검색어)
2. 메시지 바디를 통한 데이터 전송
POST, PUT, PATCH
회원가입, 상품 주문, 리소스 등록, 리소스 변경 등등
 
HTTP 헤더
header-field = field-name ":" OWS field-value OWS (OWS: 띄어쓰기 허용)
field-name은 대소문자 구문 없음
GET /search?q=hello&hl=ko HTTP/1.1
Host:www.google.com1
HTTP헤더의 용도는 (( 중복 ))
HTTP 전송에 필요한 모든 부가정보
예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보..등등
표준헤더가 매우 많음
필요시 임의의 헤더 추가 가능!

HTTP 헤더 과거에는 헤더를 분류했음.
리소스와 행위를 분리 해야함.(이것은 http 메소드를 통해 가능 )
 
HTTP 상태 코드
클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
1xx (informational) : 요청이 수신되어 처리중
2xx (Successful) : 요청 정상 처리
3xx (Redirection) : 요청을 완료하려면 추가 행동이 필요
4xx (Client Error) : 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
5xx (Server Error) : 서버 오류, 서버가 정상 요청을 처리하지 못함.
 
표현
Content-Type : 표현 데이터의 형석
Content-Encoding : 표현 데이터의 압축 방식
Content-Language : 표현 데이터의 자연 언어
Content-Length : 표현 데이터의 길이
표현 헤더는 전송, 응답 둘다 사용
 
Content-Type( 표현 데이터의 형식 설명 )
미디어 타입, 문자 인코딩
예) text/html; charset=utf-8 , application/json , image/png(이미지 관련 컨텐트타입)
Content-Encoding( 표현 데이터 인코딩 ) 압축용
표현 데이터를 압축하기 위해 사용
데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가
데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축 해제
Content-Language(표현 데이터의 자연 언어)
예) ko, en, en-US
메시지 본문안에 표현 본문안에 표현 데이터의 언어
Content-Length(표현 데이터의 길이)
바이트 단위
 
협상 헤더(콘텐츠 네고시에이션)
클라이언트가 선호는 표현 요청
Accept : 클라이언트가 선호하는 미디어 타입 전달
Accept-Charset : 클라이언트가 선호하는 문자 인코딩
Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
Accept-Language: 클라이언트가 선호하는 자연 언어
협상 헤더는 요청시에만 사용!
 
전송 방식 설명
단순 전송
한번에 요청하고 한번에 받는 방식
압축 전송
서버에서 압축해서 보내줌 용량이 줄어들어서 좋음.
Content-Encoding: gzip 이런걸 추가해줘야함.
분할 전송
Transfer-Encoding : chunked 쪼개서 보내겠다는 의미임.
바이트 단위로 쪼개서보냄 / 분할해서 전송하면 오는대로 표현할 수 있음.
이걸 사용할때는 ContentLength를 사용하면 안댐. 길이를 분할해서 보내기때문에 모름
ex) 5 Hello 5 Wolrd
범위 전송
범위를 지정해서 받을 수 있음.
 
일반 정보
From ( 유저 에이전트의 이메일 정보 )
일반적으로 잘 사용되지 않음
검색 엔진 같은 곳에서, 주로 사용
요청에서 사용
 
Referrer(이전 웹 페이지 주소)
현재 요청된 페이지의 이전 웹 페이지 주소
A -> B로 이동하는 경우 B를 요청할 때 Referrer: A 를 포함해서 요청
Referrer를 사용해서 유입 경로 분석 가능
요청에서 사용
 
User-Agent(유저 에이전트 애플리케이션 정보)
클라이언트의 애플리케이션 정보(웹 브라우저 정보, 등등)
통계 정보
어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능
요청에서 사용
 
Server(요청을 처리하는 Origin서버의 소프트웨어 정보)
실제 http요청을 보내면 많은 서버를 거쳐서 가게됨( 노드 )
마지막에 실제 나의 요청을 받는 끝에있는 http응답을 해주는 진짜 서버를 Origin서버라함.
(나의 요청에 응답하는 마지막 서버)
응답에서 사용한다.
 
Date( 메시지가 발생한 날짜와 시간 )
응답에서 사용
 
Host 헤더 ( 요청한 호스트 정보(도메인))
요청에서 사용
필수
하나의 서버가 여러 도메인을 처리해야 할 때
하나의 IP주소에 여러 도메인이 적용되어 있을 때
이때 구분을 해줌
 
인증 관련 헤더
(클라이언트 인증 정보를 서버에 전달)
Authorizaion: Basic xxxxxxxxxxxxx
 
쿠키
Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답)
Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달