[네트워크] HTTP - Hypertext Transfer Protocol

개념

OSI 7 계층 : 네트워크 통신을 위한 표준 프로토콜 구조 정의한다. 상위 계층일수록 사용자와 더 가까운 기능을 제공한다.

프로토콜 : 컴퓨터 네트워크에서 데이터 통신을 위한 규칙이나 약속을 의미한다. 이를 통해 다른 시스템끼리 상호작용할 수 있고, 데이터가 정확하고 일관되게 전송될 수 있도록 한다.

OSI 7 Layer의 응용-전송-세션-표현-애플리케이션 계층 중 애플리케이션에 통신에서 사용되는 프로토콜이다.

 

여러 종류의 프로토콜 중

HTTP 는 웹페이지와 데이터를 전송하는 프로토콜 이다.

브라우저와 서버 간에 데이터를 주고받기위한 방식으로 사용하고 있다.

 

특징

• 비연결성 Connectionless : 클라이언트와 서버의 연결을 지속하지 않고, 각 요청마다 새로운 연결을 잇는다.
  • 각각의 http 요청에 독립적으로 응답을 보낸 후 연결을 끊는다.
• 무상태성 Stateless: 각 요청은 독립적이고, 이전 요청의 상태를 기억하지 않는다. 클라이언트의 상태를 서버는 저장할 필요가 없기때문이다.
  • 이전 통신의 정보를 모르기 때문에, 매번 인증을 해줘야 한다.
• 요청/ 응답 모델 : 클라이언트가 요청을 보내면 서버가 응답을 반환하는 구조
• 메서드 : GET, POST, PUT, DELETE. 클라이언트가 서버에서 사용자 요청의 목적을 알리는 수단이다.

 

HTTP 는 평문 데이터를 전송하는 프로토콜이기 때문에, 중요한 정보를 주고받으면, 제 3자에 의해 조회될 위험이 있다.

HTTPS : HTTP 에 암호화가 추가된 프로토콜이다. SSL을 적용한 것이다.

SSL : Secure Socket Layer. 인터넷을 통해 전달되는 정보를 보호하기 위해 개발한 통신 규약

원래는 TCP와 직접 통신했지만,

HTTPS 에서 HTTP 는 SSL과 통신하고 > SSL이 TCP와 통신함 = 암호화, 증명서, 안전성 보호를 이용할 수 있게 된다.

 

무상태성 stateless

각각의 데이터 요청이 서로 독립적으로 관리된다.

매 통신마다 필요한 모든 정보를 담아서 보내야한다.

특징

• 이전 요청과 관계없이 처리된다
• 각 요청은 별도로 인식한다
• 클라이언트 상태를 저장하지 않는다

장점

• 메모리, 자원의 사용이 줄어 서버 부하가 감소한다
• 요청을 여러 서버중 어디에서든 처리될 수 있어, 로드밸런싱과 같은 기술을 통해 시스템을 확장할 수 있다.
• 서버가 상태정보를 관리하지 않아 유지관리가 단순해진다.

단점

클라이언트와 서버 간의 연속된 상태정보를 필요로 하는 경우에 문제가 발생한다.

EX) 로그인 세션, 장바구니 등

해결하기 위해 다음 세가지 추가적인 방법으로 상태를 관리한다.

• 쿠키 Cookie : 클라이언트 측에 상태정보를 저장한다. 요청에 서버에 같이 전송한다.
• 세션 Session : 서버가 클라이언트의 상태 정보를 저장하는 방법이다. (세션 ID를 쿠키 형태로 송수신)
• 토큰 기반 인증 : 서버로부터 인증토큰을 받아서 요청시에 같이 전송한다. RESTful API 에 자주 사용된다.
• 로컬스토리지

HTTP 버전

HTTP 0.9

초기 http 버전 - 1996

• 비지속적 연결
• 단일 요청/응답
• 기본적인 요청/응답 헤더를 사용

간단한 구조로 구현에 용이함.

요청당 연결을 생성, 종료해야 하므로 오버헤드가 크고 성능이 떨어진다.

HTTP 1.1

• 지속적 연결
• 다중 요청 처리
• 캐시 제어 및 조건부 요청 기능 강화
• host 헤더가 필수로 추가되어 여러 도메인을 지원한다.

연결 재사용과 캐시기능으로 데이터 전송 속도가 향상되었다.

TCP 사용으로 인해 대기 시간이 발생할 수 있다.

HTTP 2

• 다중화: 하나의 연결에서 여러 요청과 응답을 동시에 처리할 수 있다.
• 헤더 압축: HPACK을 사용하여 헤더 크기를 줄인다.
• 서버 푸시: 서버가 클라이언트 요청 없이 리소스를 미리 전송할 수 있다.

지연 시간 감소 및 대역폭 효율성 개선됨 - 성능향상

초기 구현 복잡할 수 있음.

구형 클라이언트와 서버에 호환성에 문제가 발생함.

HTTP 3

• QUIC 프로토콜 기반: UDP를 사용으로 더 빠른 연결 성능
• 0-RTT 연결 설정: 초기 연결 시간을 단축
• 패킷 손실 처리: 손실된 패킷만 재전송하여 성능을 개선한다.

모바일 환경 및 불안정한 네트워크에서 더 나은 성능을 가진다.

QUIC로 서버와 클라이언트의 지원이 필요하며, 초기 채택이 제한적이다.

QUIC?

Quick UDP Internet Connections

google 개발, http 3의 기반이 된다.

TCP 대신 UDP 를 사용해 연결 설정, 데이터 전송한다.

• 0-RTT 연결 설정 : 핸드쉐이크 없이 데이터 전송을 가능하게 한다.
• 다중화
• 내장된 암호화
• 패킷 손실 복구

 

정리

특성	HTTP 1.0	HTTP 1.1	HTTP 2	HTTP 3
출시 연도	1996	1999	2015	2020
연결 방식	비지속적	지속적	지속적	지속적
요청/응답 처리	단일	다중	다중화 지원	다중화 지원
헤더 처리	기본 헤더	캐시 및 조건부 요청 지원	헤더 압축 HPACK	헤더 압축 QUIC
서버 푸시	없음	없음	지원	지원
전송 프로토콜	TCP	TCP	TCP	QUIC (UDP)
성능	느림	개선됨	크게 향상됨	매우 향상됨

 

URL

서버에 자원을 요청하기 위해 입력하는 영문주소

출처 : https://velog.io/@simoniful

 

Request 요청

클라이언트에서 서버에 데이터 처리에 필요한 요청을 보내는 메시지

구조

라인 Line

메서드 HTTP Request Methods : 요청의 종류

• GET 조회 : 존재하는 데이터 요청
  • 데이터가 헤더 URL 에 노출되므로 보안적으로 중요한 데이터는 전달하면 안된다.
  • EX) http://localhost:8080/boardList?name=제목&contents=내용
• POST 생성 : 새로운 데이터 생성
  • 데이터는 바디에 추가된다. URL 에 데이터가 노출되지 않아 GET 보다 안전하다. 
  • EX) http://localhost:8080/addBoard
  • PUT, DELETE 동작도 수행 가능
• PUT 변경 : 존재하는 특정 데이터 업데이트. 해당 데이터가 없으면 추가 생성된다.
• PATCH 수정 : 존재하는 특정 데이터 일부 업데이트
• DELETE 삭제 : 존재하는 데이터 삭제

URI(Uniform Resource Identifier): 요청할 리소스의 위치를 나타낸다.

HTTP 버전: 사용하는 HTTP 프로토콜의 버전을 명시한다.

Method URI HTTP버전
GET /index.html HTTP/1.1

 

헤더 Headers

`키: 값` 형태로 구성.

Content-Type : 요청 데이터 형식을 정의. `type/subtype` 형식

Authorization : 클라이언트가 서버에 인증 정보를 제공하기 위해 사용된다. 보안이 필요한 API 요청에서 사용된다. 인증방법과 인증정보를 포함한다. EX) Basic Authentication, Bearer Token

Headers: {
    Host: 요청을 보내는 목표(타겟)의 주소. 즉, 요청을 보내는 웹사이트의 기본 주소(ex. www.apple.co.kr)
    User-Agent: 요청을 보내는 클라이언트의 대한 정보 (ex. chrome, firefox, safari, explorer)
    Content-Type: 해당 요청이 보내는 메세지 body의 타입 (ex. application/json)
    Content-Length: body 내용의 길이
    Authorization: 회원의 인증/인가를 처리하기 위해 로그인 토큰
}

등 이 있음.

본문 Body

선택적 요소. JSON, XML 등 형식

post 에서 데이터를 같이 보낼때 사용된다.

{
    "username": "example",
    "password": "12345"
}

Response 응답

클라이언트의 요청에 대한 결과를 서버가 전달하는 역할을 한다.

구조

라인 Line

HTTP 버전: 사용하는 HTTP 프로토콜의 버전

상태 코드(Status Code): 요청의 처리 결과를 나타내는 숫자 코드이다.

상태 메시지(Status Message): 상태 코드를 설명하는 짧은 메시지

HTTP버전 상태코드 상태메시지
HTTP/1.1 200 OK

헤더 Headers

`키: 값` 형태로 구성.

요청 헤더와 같음. 응답은 추가정보(메타데이터)를 담고있는 부분이 있다.

본문 Body

리소스의 실제 내용을 포함한다.

HTML 문서, JSON 데이터 등의 형식

 

Response Status Code 응답 상태 코드

npm 에서 쉽게 확인할 수 있는 패키지가 있다http-status-code

실제 통신 시 정상적으로 응답이 되었는지, 안되었는지 파악할 수 있다.

요청을 처기한 결과를 3자리 숫자로 나타낸다. 정보응답, 성공, 리다이렉션, 클라이언트 오류, 서버 오류 등의 상태가 있다.

1. 정보 응답 (1xx)
   • 100 Continue: 클라이언트가 요청을 계속 진행해도 좋다는 의미
   • 101 Switching Protocols: 클라이언트가 요청한 프로토콜로 전환할 때
2. 성공 (2xx)
   • 200 OK: 요청이 성공적으로 처리되었음
   • 201 Created: 요청이 성공적으로 처리되었고, 새로운 리소스가 생성되었음
   • 202 Accepted: 요청이 수락되었으나, 아직 처리되지 않았음.
   • 204 No Content: 요청이 성공하였으나, 반환할 내용이 없음
3. 리다이렉션 (3xx)
   • 300 Multiple Choices: 요청한 리소스에 여러 개의 선택이 있음
   • 301 Moved Permanently: 요청한 리소스가 영구적으로 다른 URI로 이동했음
   • 302 Found: 요청한 리소스가 임시적으로 다른 URI에 위치하고 있음
   • 304 Not Modified: 클라이언트가 캐시한 리소스가 수정되지 않았음
4. 클라이언트 오류 (4xx)
   • 400 Bad Request: 서버가 요청을 이해할 수 없음. 잘못된 구문이 포함된 경우.
   • 401 Unauthorized: 요청한 리소스에 접근하기 위한 인증이 필요함.
   • 403 Forbidden: 요청이 이해되었으나, 서버가 요청을 거부했음
   • 404 Not Found: 요청한 리소스를 찾을 수 없음
   • 409 Conflict: 요청이 서버의 현재 상태와 충돌할 때 발생
5. 서버 오류 (5xx)
   • 500 Internal Server Error: 서버에서 요청을 처리하는 동안 예기치 않은 오류가 발생했음
   • 501 Not Implemented: 서버가 요청된 기능을 지원하지 않음
   • 502 Bad Gateway: 서버가 게이트웨이 또는 프록시 역할을 할 때, 상위 서버로부터 잘못된 응답을 받았음
   • 503 Service Unavailable: 서버가 현재 요청을 처리할 수 없는 상태임을 의미함. (예: 유지보수 중)
   • 504 Gateway Timeout: 서버가 상위 서버로부터 적시에 응답을 받지 못했음.

 

웹 동작 방식

www.naver.com  에 접속할때 생기는 네트워크 과정

출처 : https://mangkyu.tistory.com/91

1. 사용자가 브라우저에 URL 을 입력한다.
2. DNS 서버에 도메인 네임으로 서버의 진짜 주소를 찾는다.
3. IP 주소로 웹서버에 TCP 3 handshake 로 연결 수립한다.
4. 클라이언트는 웹 서버로 HTTP 요청 메시지를 보낸다.
5. 웹서버는 HTTP 응답 메시지를 보낸다.
6. 도착한 HTTP 응답 메시지는 웹 페이지 데이터로 변환되고, 웹 브라우저에 의해 출력된다.