[웹을 지탱하는 기술] HTTP(2)

ekil·2022년 11월 14일
0

개발도서

목록 보기
3/4
post-thumbnail

📘 책을 읽으며 알게 된 지식을 정리하고 있습니다. 현재 읽고 있는 책은 야마모토 요헤이, <웹을 지탱하는 기술> (멘토르, 2011)입니다.

📍 저작권 상 문제가 있다면 글 삭제하도록 하겠습니다. 문제가 있으면 알려주세요.

📍 간략히 정리한 것이라 실제 책을 읽어보시면 많은 도움이 될 것이라 확신합니다. 자세히 알고 싶은 내용이셨다면 책을 살펴보시는 것을 추천합니다!

📌 오늘 다룰 것은 3부 HTTP(chapter 8 ~ 9, pp.171~230)에 해당하는 내용입니다.

1. 상태 코드

✔️ 응답 메시지 첫 줄 status line에서 가장 중요한 것

RFC 2616에서 HTTP 1.1의 status code 확인하기

✔️ 상태 코드는 3자리 숫자

  • 1nn: 처리 중

  • 2nn: 성공

    • 200 OK: 요청 성공

    • 201 Created: 리소스 새로 작성 성공

  • 3nn: 리다이렉트 (이 코드 받았다면, Location 헤더를 보고 새로운 리소스로 접속하게 해줄 것)

    • 301 Moved Permanently: 해당 리소스는 Location 헤더로 전해준 URI로 "영구적으로" 이동되었음을 의미함 (일시적 변경은 302)

    • 303 See Other: 리다이렉트 처리 결과를 취득(=GET)할 수 있는 다른 URI를 알려줌(Location 헤더에 담아). PUT/POST로 리소스를 조작하고, 그 결과를 GET으로 가져오도록 하기 위해 사용

      내용을 수정하거나 추가하고 그 변경사항이 반영된 결과를 바로 볼 수 있는 것이 일반적이니까, 그런 결과를 볼 수 있게, Location 헤더에 담은 URI로 GET 요청을 보냄으로써 그 작업을 완성하라는 것인 듯?

    -> 3nn을 받으면, 응답 메시지 Location 헤더에 담긴 URI로 클라이언트에서 추가로 요청을 보내야 하는 것인 듯?!

  • 4nn: 클라이언트 에러 -> 잘못된 요청을 보냈을 때.

    • 400 Bad Request: 요청 구문이나 파라미터가 잘못됐을 때 or 클라이언트 에러 나타내기 위한 적절한 상태 코드 없을 때

    • 401 Unauthorized: 접근 권한 없음, 인증 실패. 적절한 인증 정보가 필요함.

    • 404 Not Found: 해당 리소스를 찾을 수 없음. 바디에 이유를 담음.

  • 5nn: 서버 에러, 서버에서 원인 해결하면, 동일한 요청 재전송했을 때 정상적인 결과 받을 가능성 有

    • 500 Internal Server Error: 서버 내부 에러 발생으로 정상 응답 보낼 수 없을 때 or 서버 에러 나타내기 위한 적절한 상태 코드 없을 때

    • 503 Service Unavailable: 서버 점검 등의 이유로 일시적으로 해당 서버에 엑세스 불가, Retry-After 헤더로 서비스 재개 시기가 대략 몇 초 후인지 알려줄 수 있음

⭐ 이처럼 상태 코드는 고정돼 있으므로, 임의로 추가할 수 없고, 이들을 올바르게 사용하는 것이 중요!

2. HTTP 헤더

✔️ Email 메시지 스펙(RFC 822)과 유사한 부분 多

📍 MIME 미디어 타입

  • MIME = Multipurpose Internet Mail Extensions, Email에서 차용한 스펙임을 이름에서 알 수 있음

    복수의 메일 헤더를 정의하는 스펙임

    HTTP에서는 그중 몇 개만을 이용

  • MIME 미디어 타입 = '미디어 타입'

Content-Type

  • 메시지의 바디 내용이 어떤 type(종류)인지를 미디어 타입으로 나타냄

    ex. Content-Type: application/xhtml+xml; charset=utf-8

    ✔️ application = 타입 (text, image 등 9개의 타입이 있음)

    ✔️ xhtml+xml = 서브타입 (XHTML 문서를 의미함)

    ✔️ charset 파라미터 = 문자 인코딩 방식 지정

Content-Language

  • 리소스 표현의 자연 언어를 지정

    ex. Content-Language: ko-KR

    ✔️ ko = ISO 639가 정의하는 언어 코드 (ko, en)

    ✔️ KR = ISO 3166이 정의하는 지역 코드 (KR, US)

📍 Content-Type(미디어 타입 & 인코딩 방식), Content-Language 이용해 서버가 일방적으로 결정할 수도 있고, 클라이언트와 콘텐트 네고시에이션을 통해 정할 수도 있음

Accept

  • 클라이언트에서 처리할 수 있는 미디어 타입을 서버에게 전달할 때 이용

    ex. Accept: text/html, application/xhtml+xml, application/xml; q=0.9, */*;q=0.8

    ✔️ 우선도: qvalue(= q 파라미터의 값)로 나타냄, 0~1의 값 갖고, 클수록 우선도 높음

    • text/html, application/xhtml+xml = 1 (기본값)

    • application/xml = 0.9

    • 나머지 모든 미디어 타입 = 0.8

✔️ Accept 헤더에 지정한 미디어 타입에 서버가 대응하지 않고 있다면 406 Not Acceptable 반환

Accept-Charset

  • 클라이언트에서 처리할 수 있는 문자 인코딩을 서버에 전달할 때 이용

    ex. Accept-Charset: EUC-KR;utf-8;q=0.7, */*;q=0.7

    ✔️ EUC-KR이 최우선, Accept-Charset 헤더의 기본 문자 인코딩인 ISO 8859-1이 그 다음 우선(우선도는 둘 다 1), UTF-8 및 그밖의 방식이 0.7의 우선도

Accept-Language

  • 클라이언트에서 처리할 수 있는 언어를 서버에 전달할 때 이용

    ex. Accept-Language: ko, en-us;q=0.7, en;q=0.3

    ✔️ 한국어가 1, 미국 영어가 0.7, 지역 특정하지 않는 영어가 0.3의 우선도

WWW-Authenticate

  • 응답 메시지에서, 401 Unauthorized와 함께, 리소스 접근에 어떤 인증 정보가 필요한지 알려줄 때 사용

캐시 관련 헤더

캐시

  • 서버로부터 가져온 리소스를 로컬 스토리지에 저장해 재사용하는 방법 또는 로컬 스토리지에 캐싱한 데이터 자체

  • 클라이언트: 서버에서 가져온 리소스의 캐시 가능 여부 조사, 가능하면 로컬 스토리지에 저장함

Pragma

Pragma: no-cache

-> 값을 캐시하지 마시오!

Expires

  • 캐시의 유효기간을 나타냄

  • 클라이언트: 유효기간 확인하고, 캐시를 이용할지 서버에 다시 접속할지를 결정

  • 리소스 변경 가능성이 없는 리소스더라도 1년 이내의 기간을 설정할 것

Cache-Control

✔️ Pragma, Expires의 기능 + a -> 복잡한 지정을 위해 HTTP 1.1에서 추가한 헤더

Cache-Control: no-chace, Cache-Control: max-age: 86400

  • Expires의 값으로는 절대 시간만 사용 가능, Cache-Control은 상대 시간도 사용 가능

    max-age: 86400 = 지금으로부터 86400초(=24시간)동안 유효하다

Connection

  • HTTP 1.1에서부터, 서버와 클라이언트의 지속적 접속이 기본 동작이 됨

-> 클라이언트가 요청하고 서버가 응답하면 바로 TCP 커넥션을 끊던 기존 방식에서 변화한 것

✔️ Pipelining(파이프라인화): 클라이언트가 응답을 기다리지 않고, 같은 서버에 요청을 보낼 수 있음 = 효율적 메시지 처리 가능

✔️ Connection 헤더에 close 값을 지정하면 커넥션을 끊을 수 있음

ex.
GET /test HTTP/1.1
Host: example.com
Connection: close

-> 이 요청의 응답이 반환된 후 접속을 끊는다!라는 의도를 전달

📍 이것들 외에도 다양한 헤더가 존재합니다!

profile
좋아하는 일을 잘함으로써 먹고살고 싶은 프론트엔드 개발자입니다.

0개의 댓글