HTTP는 메시지는 스타트라인, 헤더, 바디로 이루어져있다.
HTTP 헤더(일반 헤더)
요청 메시지
GET /search?q=hello&hl=ko HTTP/1.1 - 스타트 라인
HOST:www.google.com -헤더
응답메시지
HTTP/1.1 200 OK - 스타트라인
Content-Type:text/html; charset=UTF-8 - 헤더
Content-Length: 3333 - 헤더용도
HTTP 전송에 필요한 모든 부가정보를 가지고 있다.
ex) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 서버 정보, 캐시 관리 정보
바디
1.
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
<html>
<body>...</body>
</html>
2.
HTTP/1.1 200 OK
Content-Type: application/json
{
"code" : 200,
"data" : {
"id" : 1,
"name" : "kim",
"age" : 20,
"gender" : "MALE"
}
}용도
메시지 본문(Message body)은 엔티티 본문(Entity body)을 전달하는데 사용한다.
엔티티 본문은 요청이나 응답에서 전달할 실제 데이터이다.
엔티티 헤더는 엔티티 본문의 데이터를 해석할 수 있는 정보를 제공한다.
RFC7230
최근에는 엔티티를 엔티티라 하지 않고, 표현(Presentation)이라 사용한다.
메시지 본문(message body)을 통해 표현 데이터를 전달.
표현은 요청이나 응답에서 전달할 실제데이터 이며, 표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공한다.
표현
Content-Type : 데이터 타입, 표현 데이터의 형식을 설명한다. 문자, 미디어, json
ex) Content-Type: text/html; charset=UTF-8(문자 인코딩)
Content-Type: application/json >> json은 기본적으로 UTF-8 형식을 가지고있다.
Content-Encoding : 데이터 압축 형식, 표현 데이터를 압축하기 위해 사용, 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축 해제
ex) Content-Encoding: gzip
Content-Language : 표현 데이터의 자연 언어를 표현
ex) Content-Language :ko, en
Content-Length : 표현 데이터의 길이, 바이트 단위로 표현한다.
ex) Content-Length: 3333
데이터 타입, 데이터 압축형식, 문자 압축형식은 다르다.협상
협상 : 클라이언트가 선호하는 표현을 요청한다.
협상의 종류
Accept : 클라이언트가 선호하는 미디어 타입을 전달한다.
Accept-Language : 클라이언트가 선호하는 자연 언어
Accept-Charset : 클라이언트가 선호하는 문자 인코딩
GET /event
Accept-Language : ko-KR,ko;q=0.9,en;q=0.8
1에 가까울수록 클라이언트가 선호하는 자연 언어이다.전송
단순 전송 : 한번에 요청하고 한번에 받는다.
압축 전송 : 요청 데이터를 서버가 압축형태로 표현데이터를 전송한다. 하지만, 압축전송을 하려면 Content-Encoding:gzip을 명시해 주어야 클라이언트가 표현데이터를 받을때 압축 형식인것을 인식할 수 있다.
분할 전송 : 응답데이터의 크기가 너무 클 경우 분할 전송을 사용한다.
일반 정보
Referer
Referer : 이전 웹 페이지 주소
현재 요청된 페이지의 이전 웹페이지 주소 Referer은 통해 유입 경로 분석 가능.
다음 페이지에 대한 데이터 요청 시 서버에서 이전 페이지에 대한 정보를 같이 담아서 보낸다.
User-Agent
User-Agent : 클라이언트의 애플리케이션 정보(웨 브라우저 정보)
특정 브라우저, 애플리케이션에 대한 정보를 얻고, 특이한 애플리케이션이나 브라우저에서 에러가 발생할 경우 애플리케이션 추적이 가능하다.
특별한 정보
Host
Host: 클라이언트가 요청한 호스트 정보(도메인). 요청 메시지에서 Host는 필수 값이다.
메인 서버에서 Host가 존재하지 않는 요청메시지를 받을 경우 어떤 도메인이 연결해야하는지 알 수 없다. 즉 하나의 서버 IP주소에 여러 도메인을 연결 할 수 있어서 반드시 호스트정보를 담아서 보내야한다.
Location
Location : 페이지 리다이렉션
웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동한다. 서버가 다시 연결될 URL을 Location에 담아 보낸다. 클라이언트는 자동적으로 다시 요청메시지를 Location에 연결하도록 전송한다.
Allow
Allow : 허용 가능한 HTTP 메서드
클라이언트가 HTTP 메서드를 요청할 경우 서버에서 해당 메서드를 지원하지 않을때 응답 메시지에 포함하여 보낸다.
쿠키
쿠키 : 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달한다.
서버는 쿠키에 대한 정보를 파악하고, 쿠키의 상황에 따라 클라이언트에게 보내는 응답메시지가 다르다.
자바:
Cookie cookie = new Cookie();
cookie.setCookie();
response.addCookie();
서버:
Set-Cookie: sessionId= ; expires= ; path= ; domain= ;HTTP는 Stateless를 지향한다. 무상태이기 때문에 요청시 마다 누락된 데이터 한개도 없이 모두 보내야한다.
하지만, 쿠키가 존재할 시 쿠키에 대한 정보를 이용하여 서버는 누락된 데이터가 포함되있으면 쿠키데이터를 사용하여 응답할 수 있다.
쿠키 동작 순서
-
서버가 클라이언트로 응답할 때 쿠키가 생성된다. 응답메시지에 담긴 쿠키를 웹브라우저의 쿠키 저장소에 저장한다.
-
웹 브라우저가 페이지에 접근할 때 웹 브라우저는 쿠키 저장소에서 웹 페이지와 관련된 쿠키가 있는지 찾고, 관련 쿠키가 존재하면 해당 쿠키를 사용하고, 쿠키를 헤더에 담아 보낸다.
-
서버는 쿠키에 존재하는 데이터를 사용하고, 쿠키와 현재 서버의 데이터가 다르거나 수정할 부분이 있으면 수정하여 쿠키를 다시 응답메시지에 포함하여 보낸다.
주의사항
웹 브라우저가 쿠키를 무조건 요청 메시지와 같이 보내면 보안에 위험이 생긴다. 따라서, 서버에서 쿠키를 생성할 때 설정값들을 같이 보내 해당 서버의 요청을 할때만 쿠키를 포함하여 보내도록 설정 가능하다.
sessionId : 서버가 쿠키를 응답메시지에 같이 보낼 때 해당 쿠키 사용처를 작성하여 보낸다. 서버에 요청할때 마다 서버는 sessionId를 확인하고, Id가 일치하면 서버는 해당 쿠키를 사용한다.
쿠키 설정 정보
생명주기
Expires : expires=Tue, 22-Nov-2022 18:28:32 GMT
--> expires로 설정된 해당 날짜가 되면 쿠키는 만료된다.
max-age : max-age=1800. 쿠키는 max-age로 설정한 시간 후 만료된다.
세션쿠키 : 브라우저 종료시 쿠키가 삭제된다.
영속쿠키 : 만료날짜까지 쿠키를 유지한다.
도메인
쿠키에 도메인을 지정한다. domain= : 해당 도메인으로 요청 시 쿠키가 같이 전송되며, 하위 도메인 접근할때도 쿠키를 사용한다.
Path
path=/home
이 경로를 포함한 하위 경로 페이지만 쿠키에 접근하다.
일반적으로 path=/ 루트로 지정
