Network 키워드 2 - HTTP, URL

HTTP (Hypertext Transfer Protocol)란?

• 팀 버너스리(Tim Berners-Lee)와 그의 팀이 CERN에서 HTML, HTTP 발명
• 문서화된 최초의 HTTP버전은 HTTP v0.9(1991년)
• 서버와 클라이언트가 인터넷상에서 데이터를 주고받기 위한 프로토콜(protocol)
• HTTP/2 버전 등장

HTTP 작동방식

• HTTP는 서버/클라이언트 모델을 따름
  • Request - Response 구조
  • 클라이언트는 서버에 요청 보내고 응답 대기
  • 서버가 요청에 대한 결과를 만들어서 응답
• 무상태 프로토콜 stateless
  • 장점
    • 불특정 다수를 대상으로 하는 서비스에는 적합
    • 클라이언트와 서버가 계속 연결된 형태가 아니기 때문에 클라이언트와 서버 간의 최대 연결 수보다 훨씬 많은 요청과 응답을 처리할 수 있다.
  • 단점
    • 연결을 끊어버리기 때문에, 클라이언트의 이전 상황을 알 수가 없다.
    • 정보를 유지하기 위해서 Cookie와 같은 기술이 등장
• 비연결성
  • HTTP는 기본이 연결을 유지하지 않는 모델
  • 일반적으로 초 단위의 이하의 빠른 속도로 응답
  • 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음
    • 예) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다.
  • 서버 자원을 매우 효율적으로 사용할 수 있음
  • TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가
  • 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등등 수 많은 자원이 함께 다운로드 ⇒ 지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결
  • HTTP/2, HTTP/3에서 더 많은 최적화

HTTP 요청 메서드

• GET : 정보를 요청하기 위해서 사용 (SELECT)
• POST : 정보를 밀어넣기 위해서 사용 (INSERT)
• PUT : 정보를 업데이트하기 위해서 사용 (UPDATE)
• DELETE : 정보를 삭제하기 위해서 사용 (DELETE)
• HEAD : (HTTP)헤더 정보만 요청, 해당 자원이 존재하는지 혹은 서버에 문제가 없는지를 확인하기 위해서 사용
• OPTIONS : 웹서버가 지원하는 메서드의 종류를 요청
• TRACE : 클라이언트의 요청을 그대로 반환, echo 서비스로 서버 상태를 확인하기 위한 목적으로 주로 사용

HTTP 상태 코드

• 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
• 1xx (Informational): 요청이 수신되어 처리중

• 2xx (Successful): 요청 정상 처리

  코드	이름	내용
  200	OK	요청 성공
  201	Created	요청 성공해서 새로운 리소스 생성 (생성된 리소스는 응답의 Location 헤더 필드로 식별)
  202	Accepted	요청이 접수되었으나 처리가 완료되지 않았음
  204	No Content	서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음

• 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요
  • 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동 (리다이렉트)

  코드	이름	내용
  300	Multiple Choices	안 씀
  301	Moved Permanently	영구적, 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)
  302	Found	일시적, 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)
  303	See Other	일시적, 302와 같은 기능, 리다이렉트시 요청 메서드가 GET으로 변경
  304	Not Modified	캐시 목적, 클라이언트에게 리소스가 수정되지 않았음을 알려줌 -> 클라이언트는 로컬 PC에 저장된 캐시를 재사용(캐시로 리다이렉트), 로컬 캐시를 써야 하니까 응답에 메세지 바디를 포함 X
  307	Temporary Redirect	일시적, 302와 같은 기능, 리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다. MUST NOT)
  308	Permanent Redirect	영구적, 301과 같은 기능, 리다이렉트시 요청 메서드와 본문 유지

• 4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음

  코드	이름	내용
  400	Bad Request	클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
  401	Unauthorized	클라이언트가 해당 리소스에 대한 인증이 필요함
  403	Forbidden	서버가 요청을 이해했지만 승인을 거부함
  404	Not Found	요청 리소스를 찾을 수 없음

• 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함

  코드	이름	내용
  500	Internal Server Error	서버 문제로 오류 발생
  503	Service Unavailable	서비스 이용 불가

참고: ❓ 만약 모르는 상태코드가 나타나면?, 클라이언트가 인식할 수 없는 상태코드를 서버가 반환하면?

• -> 클라이언트는 상위 상태코드로 해석해서 처리
  • 미래에 새로운 상태 코드가 추가되어도 클라이언트를 변경하지 않아도 됨

HTTP 헤더

RFC2616 (과거)

출처: MDN Web Docs

• General 헤더: 메시지 전체에 적용되는 정보, 예) Connection: close
• Request 헤더: 요청 정보, 예) User-Agent: Mozilla/5.0 (Macintosh; ..)
• Response 헤더: 응답 정보, 예) Server: Apache
• Entity 헤더: 엔티티 바디 정보, 예) Content-Type: text/html, Content-
• Length: 3423
• 메시지 본문(message body)은 엔티티 본문(entity body)을 전달하는데 사용
• 엔티티 본문은 요청이나 응답에서 전달할 실제 데이터
• 엔티티 헤더는 엔티티 본문의 데이터를 해석할 수 있는 정보 제공
• 데이터 유형(html, json), 데이터 길이, 압축 정보 등등

RFC7230

• 엔티티(Entity) -> 표현(Representation)
• Representation = representation Metadata + Representation Data
• 표현 = 표현 메타데이터 + 표현 데이터
• 메시지 본문(message body)을 통해 표현 데이터 전달
• 메시지 본문 = 페이로드(payload)
• 표현은 요청이나 응답에서 전달할 실제 데이터
• 표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공
  • 데이터 유형(html, json), 데이터 길이, 압축 정보 등등
• 참고: 표현 헤더는 표현 메타데이터와, 페이로드 메시지를 구분해야 하지만, 여기서는 생략

표현

• Content-Type: 표현 데이터의 형식
  • text/html; charset=utf-8
  • application/json
  • image/png
• Content-Encoding: 표현 데이터의 압축 방식
  • 표현 데이터 압축
  • 데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가
  • 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축 해제
• Content-Language: 표현 데이터의 자연 언어
• Content-Length: 표현 데이터의 길이
  • Transfer-Encoding(전송 코딩)을 사용하면 Content-Length를 사용하면 안됨

협상(Content negotiation) - 클라이언트가 선호하는 표현 요청

• Accept: 클라이언트가 선호하는 미디어 타입 전달
• 협상 헤더는 요청 시에만 사용
• quality value: 0 ~ 1에서 클수록 높은 순위
• 구체적인 것이 우선

전송 방식

• 단순
  • 한번에 요청하고 한 번에 쭉 받는 것
• 압축
  • 압축해서 → content encoding 필요
• 분할
  • Transfer-Encoding: chunked
  • 바이트 명시, 끝나는대로 전송, 오는대로 바로 표시
  • Content length가 예상이 안되니까 넣으면 안됨
• 범위
  • Content Range

일반 정보

• From: 유저 에이전트의 이메일 정보 - 요청에서 사용
• Referer: 이전 웹 페이지 주소 - 요청에서 사용
• User-Agent: 유저 에이전트 애플리케이션 정보 - 요청에서 사용
• Server: 요청을 처리하는 오리진 서버의 소프트웨어 정보 - 응답에서 사용
• Date: 메시지가 생성된 날짜 - 응답에서 사용

특별한 정보 - 요청에서 사용

• Host: 요청한 호스트 정보(도메인)
• 필수
  • 하나의 서버가 여러 도메인을 처리해야 할 때
  • 하나의 IP 주소에 여러 도메인이 적용되어 있을 때
• Location: 페이지 리다이렉션
  • 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동
  • 201 (Created): Location 값은 요청에 의해 생성된 리소스 URI
• Allow: 허용 가능한 HTTP 메서드
• Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

인증

• Authorization: 클라이언트 인증 정보를 서버에 전달
• WWW-Authenticate: 리소스 접근시 필요한 인증 방법 정의

---

URL (Uniform Resource Locator)

• 인터넷 상의 자원의 위치
• 특정 웹 서버의 특정 파일에 접근하기 위한 경로 혹은 주소
• URL은 http:로 시작하는 것뿐만 아니라 다양한(file:, mailto:, …) 것들이 준비되어 있음 -> 브라우저는 웹 서버에 액세스하는 클라이언트 뿐만 아니라 파일 다운/업로드 하는 FTP 클라이언트 기능이나 메일의 클라이언트 기능 등 복합적인 클라이언트 소프트웨어기 때문

URI = URN + URL

• 리퀘스트 메세지
  • 무엇을: URI (또는 URL을 그대로)
  • 어떻게: 메소드

URL / 로 끝나는 것과 아닌 것 차이

• /로 끝난 것: /의 다음에 써야 할 파일명을 쓰지 않고 생략
  • 파일명 생략할 때를 대비해 파일명을 미리 서버측에 설정
• /도 생략: 경로명이 아무 것도 없는 경우에는 루트 디렉토리 아래에 있는 미리 설정된 파일명의 파일

참고

책 - 모두의 네트워크

책 - 성공과 실패를 결정하는 1%의 네트워크 원리

강의 - 인프런 - 모든 개발자를 위한 HTTP 웹 기본 지식

강의 - 부스트코스 - 웹 백엔드