요청을 보낼 때 http header와 body를 보낸다. 받을 때도 동일하게.
서버에서 설정하는 헤더를 응답헤더
클라이언트에서 설정한 헤더를 요청헤더
일반헤더:
요청헤더: 클라이언트가 서버에 요청할 때 클라이언트가 설정하는 또는 자동으로 설정되는 헤더.
응답헤더: 서버가 클라이언트에게 응답을 보낼 때 설정하는 또는 자동으로 설정되는 헤더
HTTP 헤더자체가 유연하게 설계가 되어있어서 커스텀하게 만들 수 있지만 보통은 지정되어있는 key 값에 value를 담아서 헤더를 설정한다.
HTTP 헤더를 그냥 단순하게 공부해서는 업무연관성이 적어서 더 공부하기가 어려운 것 같다.
웹 개발을 하던 실제 HTTP 통신을 하는 서비스를 다뤄보아야 할 것 같다.
트러블 슈팅을 하기위해서 많은 계층 중에서 HTTP Header를 공부하려고 했지만 생각보다 쉽지 않다.
현 시점에서 만약 HTTP Header에 문제로 인해 발생한 트러블슈팅을 해야한다면, 해당 문제가 HTTP통신이라는 것으로만 일축시키고 해당 부분을 개발한 담당자에게 전달하는 것이 내 역할의 최대인듯하다.
RFC(Request for Comments): 미국의 국제 인터넷 표준화기구인 IETF(Internet Engineering Task Force)에서 제공, 관리하는 문서로, 인터넷 개발에 있어서 필요한 기술, 연구 결과, 절차 등을 기술해놓은 메모를 나타낸다. 거의 모든 인터넷 표준은 항상 RFC로 문서화가 되어있다.
RFC 문서를 열람할 수 있는 사이트: https://www.rfc-editor.org/
URI(Uniform Resource Identifier, 통합 자원 식별자): 인터넷에 있는 자원을 나타내는 유일한 주소.
scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]
조악하지만 예시를 만들어본다면..
http://ec2-user:abc123@localhost:8080/login?user#123
1. scheme: 사용할 프로토콜, 리소스에 따라 어떻게 요청 및 접근할 것인지를 명시한다. 웹에서 주로 HTTP 프로토콜을 사용한다.
2. user, password/사용자정보: 서버에 접근하기 위한 사용자의 이름, 비밀번호
3. host: 도메인 혹은 IP, 접속하고 싶은 서버 컴퓨터를 의미한다.
4. path: 서버에 제공하는 자원의 경로, 요청하는 경로를 MVC패턴으로 숨길 수 있다.
5. query: 클라이언트가 서버에 요청 시 전송할 데이터 (키 + 값)
6. fragment: 서브리소스에 대한 방향을 제공하는 식별자이다.
포트의 경우 기본포트가 있다. https:443, http:80, mysql:3306
?가 붙은 부분은 get 방식이며 주소에 실어서 보내는 방법이다.
post 방식은 header안에 정보를 실어서 보낸다.
fragment는 요소에 대한 id이다.
ex) #footer
href="id"
URL(Uniform Resource Locator): 웹주소, 컴퓨터 네트워크 상에서 리소스가 어디있는지 알려주기 위한 규약이다.
URI는 URL과 URN을 포함한다.
https://new.naver.com/main/read.naver?mode=LSD&mid=shm&sid1=101&oid=421&aid=0005584531
전체가 URI라고 했을 때
URL은 https://new.naver.com/main/read.naver?
URN은 new.naver.com/main/read.naver?mode=LSD&mid=shm&sid1=101&oid=421&aid=0005584531
이다.
www.naver.com에 요청을 한다라고 했을 때, 나오는 화면은 여러가지 API에 요청을 해서 받은 컨텐츠들로 구성이 되어있다.
count.nhn api를 예로들면, count.nhn api요청에 대한 응답은 General, Respone Headers, Request Headers, Body로 구성된 응답을 받게 된다.
Body는 HTML, XML, JSON 등의 본문을 구성하고 있다.
Response Header(응답헤더)는 서버에서 설정된다.
Request Header(요청헤더)는 클라이언트에서 설정된다.
헤더는 콜론 ':' 으로 서로 구분되는 key - value 형태로 설정됩니다.
HTTP 요청을 할 때 3가지의 헤더인 일반헤더, 요청헤더, 응답헤더가 자동으로 생깁니다.
여기서 서버에서 설정하는 헤더를 응답헤더, 클라이언트에서 설정한 헤더를 요청헤더라고 합니다.
일반헤더
요청한 URL, 요청메서드, 해당 자원을 요청할 때 해당 자원의 출처를 나타내는 URL을 노출시킬지 말지를 정하는 보안정도가 설정되어있는 Referer Policy 등이 들어갑니다.
요청헤더 (사용자의 장치에 대한 정보)
요청 헤더는 클라이언트가 서버에 요청할 때 클라이언트가 설정하는 또는 자동으로 설정되는 헤더를 말합니다. 요청 헤더에는 메서드, 클라이언트의 OS, 브라우저 정보 등이 담깁니다.
응답헤더
응답헤더는 서버가 클라이언트에게 응답을 보낼 때 설정하는 또는 자동으로 설정되는 헤더를 말합니다.
응답 헤더는 서버의 소프트웨어 정보 등이 담깁니다. 예를 들어 nginx를 프록시서버로 두었다면 해당 정보가 표기됩니다. 하지만 대부분의 서버는 일반적으로 해커가 서버에서 어떤 소프트웨어가 사용되고 있는지 알기 어렵게 하기 위해 서버 정보를 숨깁니다.
response Headers의 server : NWS 라고 되어있는데 이는 Naver Web Server를 의미합니다.
gzip 압축 알고리즘을 쓰는 것만 나와있을 뿐 자세하게 표기가 안되는 것을 볼 수 있습니다.
HTTP 헤더 자체가 굉장히 유연하게 설계가 되어있어서 커스텀하게 만들 수 있지만 보통은 지정되어있는 Key값에 Value를 담아서 헤더를 설정한다. 예를 들어 쿠키를 설정할 때 요청헤더에는 Cookie라는 Key에 응담헤더에는 Set-cookie라는 key에 쿠키를 담아 설정합니다.
IP Header format
Packet이라는 것은 택배이다.
/Header/Payload/
= Packet
-> 일반적으로 1500 MTU(Maximum Transmission Unit)로 구성된다.
-> TCP(20)/IP(20) 이면 MSS(Maximum Segment Size)는 1460으로 구성된다.