HTTP Header

강재민·2024년 3월 8일
0

요청을 보낼 때 http header와 body를 보낸다. 받을 때도 동일하게.

서버에서 설정하는 헤더를 응답헤더
클라이언트에서 설정한 헤더를 요청헤더

일반헤더:

  • 요청한 URL
  • 요청메서드
  • Referrer Policy
    • 해당 자원을 요청할 때 해당자원의 출처를 나타내는 URL을 노출시킬지 말지를 정하는 보안정도가 설정

요청헤더: 클라이언트가 서버에 요청할 때 클라이언트가 설정하는 또는 자동으로 설정되는 헤더.

  • 메서드
  • 클라이언트의 OS
  • 브라우저 정보

응답헤더: 서버가 클라이언트에게 응답을 보낼 때 설정하는 또는 자동으로 설정되는 헤더

  • 서버의 소프트웨어 정보
  • nginx라면 nginx
    • 하지만 해커가 서버의 소프트웨어 정보를 알지 못하게 정보를 숨깁니다.
    • gzip 압축 알고리즘을 씀으로 이거를 인코딩 하고 있다.

HTTP 헤더자체가 유연하게 설계가 되어있어서 커스텀하게 만들 수 있지만 보통은 지정되어있는 key 값에 value를 담아서 헤더를 설정한다.


HTTP 헤더를 그냥 단순하게 공부해서는 업무연관성이 적어서 더 공부하기가 어려운 것 같다.
웹 개발을 하던 실제 HTTP 통신을 하는 서비스를 다뤄보아야 할 것 같다.

트러블 슈팅을 하기위해서 많은 계층 중에서 HTTP Header를 공부하려고 했지만 생각보다 쉽지 않다.
현 시점에서 만약 HTTP Header에 문제로 인해 발생한 트러블슈팅을 해야한다면, 해당 문제가 HTTP통신이라는 것으로만 일축시키고 해당 부분을 개발한 담당자에게 전달하는 것이 내 역할의 최대인듯하다.


네트워크탭 사용하기

  • 요청 응답을 보낼 때는 개발자도구에 Network탭을 확인하는게 좋다.
  • Disable cache는 꺼두는게 좋다.
    • cache의 유무에 따라 요청이 완전히 달라진다.
  • 인터넷 느린환경, 안되는 환경 다 조절을 할 수가 있다.
  • HTTP는 헤더와 바디로 구성되어 있다.
    • 바디: 데이터
      • Response 탭에서 볼 수 있다.
      • GET이나 DELETE로 되어있으면 일반적으로 요청에 바디를 안보낸다.
      • POST에서 Payload를 보면 요청의 바디가 나와있다.
    • 헤더: OSIS 7계층의 데이터마다 앞에 붙는 그 헤더
      • Headers 탭에서 볼 수 있다.
        • 요청과 응답의 상태가 동시에 기록되어 있다.
  • 양 옆에 :: 찍혀있는게 있다면 HTTP2, HTTP3 이다.
    • HTTP에는 0.9, 1.0, 1.2, 2, 3 버전이 있고 요즘은 1.1, 2, 3을 혼용해서 쓴다고 한다.

RFC 보는 방법

RFC(Request for Comments): 미국의 국제 인터넷 표준화기구인 IETF(Internet Engineering Task Force)에서 제공, 관리하는 문서로, 인터넷 개발에 있어서 필요한 기술, 연구 결과, 절차 등을 기술해놓은 메모를 나타낸다. 거의 모든 인터넷 표준은 항상 RFC로 문서화가 되어있다.

RFC 문서를 열람할 수 있는 사이트: https://www.rfc-editor.org/

  • 왼쪽 사이드바에는
    • 문서검색, 정오표, 질문, 소개
  • 중앙 메인에는
    • 전체 RFC 인덱스 확인과 종류별로 RFC를 열람
  • 오른쪽 사이드바에는
    • RFC 검색 기능과 최신 RFC 리스트를 볼 수 있다.
  • 브라우저에서 보는 방법
    • rfc-editor.org/rfc/rfc8200.txt
      • 뒤에 rfc 번호를 맞춰서 입력하면 볼 수 있다.

주소 구성 체계 (URL, URI, Origin)

  • URI(Uniform Resource Identifier, 통합 자원 식별자): 인터넷에 있는 자원을 나타내는 유일한 주소.

    • 인터넷에 존재하는 각종 정보들의 유일한 이름이나 위치를 표시하는 식별자이다.
    • URI의 구조
    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을 포함한다.

    • 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으로 구성된다.


HTTP 메서드와 REST API


안전한 메서드, 멱등성 메서드


상태 코드 (1XX, 2XX)

  • 1xx: Informational
    • 요구메시지를 받은 후 연결 중 작업할 때.
  • 100: Continue
  • 101: Switching Protocols
  • 2xx: Success
    • 요구 메시지를 제대로 받았을 때.
  • 200: OK
    • 성공처리
  • 201: Created
    • 요구에 따라 새로운 자원 생성 (PUT)
  • 202: Accepted
    • 요구를 이해하였으며 진행중
  • 203: Non-Authoritative Information
  • 204: No Content
    • 요구 자료에 정보가 없음(empty)
  • 205: Reser Content
  • 206: Partial Contnet

3XX 상태코드

  • 3xx: Redirection
    • 요구메시지를 수행하기 위해 다른 작업이 필요할 때
  • 300: Multiple Choices
    • (실제 발생하지 않음)
  • 301: Moved Permanently
    • URL이 확정적으로 옮겨짐
  • 302: Moved Temporarily
    • URL이 임시적으로 옮겨짐
  • 303: See Other
  • 304: Not Modified
    • 수정 날짜에 수정되지 않음
  • 305: Use Proxy

에러 상태 코드 (4XX, 5XX)

  • 4xx: Client Error
    • 요구 메시지의 형식이 틀리거나 빠진 부분이 있얼 때.
  • 400 Bad Request
    • 요구가 올바르지 않음
  • 401 Unauthorized
    • 사용자 인증이 필요
  • 402 Payment Require
  • 403 Forbidden
    • 요구는 이해하나 수행거절(PUT)
  • 404 Not Found
    • 요구한 파일이 없음
  • 405 Method Net Allowed
    • 허락된 메소드가 아님
  • 406 Not Acceptable
  • 407 Proxy Authentication Required
    계속...
    http://coffeenix.net/doc/network/http_1_0_vs_1_1.html

컨텐츠 협상과 MIME Type


Keep-Alive, Date, Transfer-Encoding


Authorization, 기타 헤더, 커스텀 헤더


쿠키


캐시(Cache-Control)


캐시 신선도 검사


CORS


HTTPS


HTTP/2, HTTP/3


웹소켓


VPN, (포워드, 리버스)프록시/게이트웨이

0개의 댓글