요즘에는 모든 것이 HTTP이다. HTTP 메세지에 HTML 뿐만 아니라, 이미지, 영상, JSON, XMl 등등..
거의 모든 형태의 바이너리 데이터 전송이 가능하다.
서버간 데이터를 주고 받을 때도 대부분 HTTP를 사용한다.
HTTP 메세지의 구조는 크게 공통적으로
Start-line 시작라인
header 헤더
empty line 공백 라인 (CRLF)
message body 메세지 바디
위와 같은 구조로 되어 있다.
HTTP는 요청 메세지와 응답 메세지, 두개의 구조가 약간 다른데, 이미지로 살펴 보자.
이미지로 살펴 보자면, 위의 이미지와 같이 요청 메세지와 응답 메세지의 구조가 다르다
- Start-line 시작라인
요청 메세지에서 시작라인은 request-line이고, 맨 처음에는 요청 방식이 나온다. (위의 요청메세지 이미지의 GET 부분)
종류는 GET, POST, PUT, DELETE가 있는데,
GET은 서버한테 리소스를 달라고 요청하는 것이다.
POST는 데이터를 서버에 전달하여 요청 내역을 처리하도록 하는 방식이다.
path, 위의 이미지에서는 / 로 되어 있는데, 다른 예를 들면, /search?q=hello 이런식으로 된 경로를 말한다.
request-target이 되며, 요청하는 대상을 말한다.
절대 경로(absolute-path)로 시작을 하고 앞의 /search 부분을 가리킨다.
그 뒤에는 쿼리인 ?q=hello 부분이 따라서 온다. (물론 생략 가능)
그리고 http 버전을 넣는다.
응답 메세지의 시작라인은 status-line이고, 처음에는 HTTP 버전이 나오고,
요청한 상태의 코드인 200가 나온다.
상태 코드는 클라이언트가 보낸 요청이 성공했는지 실패했는지를 나타내고,
대표적인 코드로는,
200 : 성공
400 : 클라이언트 요청 오류 (클라이언트가 뭔가 잘못 보냈을 때 서버가 보내줌)
500 : 서버 내부 오류 (서버의 장애가 있거나, 문제가 있을 때 서버가 보내줌)
그 뒤에는 상태 메세지인 OK가 나온다.
상태 메세지는 사람이 읽을 수 있는 짧은 상태코드 설명 글이다.
- header 헤더
시작라인 다음에는 헤더의 값이 들어가는데,
field-name: OWS field-value OWS (OWS : 띄어쓰기 허용 (띄어써도 되고 안써도 됨))
위와 같은 구조로 되어 있다.
위의 이미지 예시로 보면, field-name은 Host가 되고 (대소문자 구분 없음)
field-value로 developer.mozilla.org 가 된다. field-value는 대소문자를 구분한다.
HTTP 헤더의 용도는 HTTP 전송에 필요한 모든 부가정보가 들어있다.
예를 들어서, 메세지 바디가 되어있는 Content-Type이 나와있고,
메세지 바디의 크기인 Content-Length도 나오고,
인증정보, 요청 클라이언트의 웹 브라우저 정보, 서버 애플리케이션의 정보, 캐시 관리 정보 등.. 이 들어있다.
쉽게 말해서, 메세지 바디빼고 필요한 메타 데이터 정보가 다 들어있다고 보면 된다.
필요시에는 임의의 헤더도 추가가 가능하다.
물론 약속한 클라이언트와 서버일 경우 이해를 한다.
- empty line 공백 라인 (CRLF)
그 다음에 공백라인이 무조건 하나 들어간다.
- message body 메세지 바디
메세지 바디는 실제 전송할 데이터이며,
HTML 문서, 이미지, 영상, JSON 등등 바이트로 표현할 수 있는 모든 데이터가 전송이 가능하다.
압축을 해서 보낸다면, 압축된 내용이 바디에 들어가게 된다.
요청 메세지에는 메세지 바디에 전송할 데이터가 없는 경우가 있는데 그러면 공백을 넣고 끝내면 된다.
(위의 응답 메세지 이미지와 같이 바디가 빈 경우도 있다.)
HTTP 는 단순하다. 하지만 확장 가능한 기술이기 때문에 크게 성공한 표준 기술이라고 할 수 있다고 정리할 수 있다.
댓글