[네트워크] OSI 7_Application Layer/HTTP 개요

Application Layer - HTTP

Application Layer의 개념을 아직 포스팅하지 못했지만, RESTful 에 대해 공부하기 전에 HTTP 개념을 잡고 가려고 한다.

💡 Application Layer = 응용 계층

HTTP

HyperText Transfer Protocol 의 약자로, Application 계층의 대표적인 프로토콜로 웹 서비스 통신에 사용된다.

클라이언트와 웹 서버 간의 데이터를 주고 받을 수 있도록 해주는 통신 규약 이다.

HTTP의 기본 구조를 기반으로 RESTful API 등의 기술을 활용하여 다양한 서비스와 애플리케이션을 개발할 수 있다.

 

Client : 브라우저, HTTP 프로토콜을 사용하여 서버에 데이터를 요청하고 서버의 응답을 받는다. (Request Message) 받은 응답을 화면에 디스플레이 한다.

Server : 웹 서버는 받은 요청에 대해 응답 메세지(Response Message)를 클라이언트에게 전송한다.

-> 이때 응답과 요청은 HTTP 메세지의 형태로 전송된다.

PC와 스마트폰이 Client가 된다.

HTTP 특징

1. TCP 통신 사용 (일반적)

  : 신뢰성 있는 통신을 제공하기 위해 연결설정을 한다.

1. Client가 socket을 생성해 서버에 TCP 연결 요청 (포트 번호 : 80)
2. Server의 TCP 연결 수락
3. Client(Web Browser)와 Server (Web Server)사이 HTTP 메세지 교환
4. TCP 연결 종료

2. HTTP는 'stateless(무상태)' 프로토콜 
→ 과거에 Client와 통신한 내용을 저장하지 않는다. 상태를 저장하는 것은 매우 복잡하다. 내용을 저장하고 유지해야하기 때문이다.

( 그래서 Cookie를 쓴다..! 이 내용은 또 나중에 포스팅 )

 

• 장점 : 서버의 확장성이 높다. → 기존의 작업을 기록하고 관리하지 않기 때문에 서버 장애 시, 백업 서버를 통해 대응이 가능하다.
  (Stateful 할 경우, 기존에 하던 작업을 기록하고 관리해야하기 때문에, 서버 장애 시 기록이 없어질 수 있어 대응이 어렵다.)
• 단점 : 클라이언트에 추가 데이터 전송을 요구한다.

3. Connectionless

: HTTP는 연결을 유지하지 않는 모델이다. 따라서 서버 자원을 효율적으로 활용할 수 있다.

하지만 TCP 연결을 위한 3-way 핸드셰이크 반복으로 오버헤드가 발생할 수 있다.

또한 웹브라우저로 사이트에 접속 시, 많은 데이터를 요구하기 때문에 packet 단위로 connection 연결/종료을 하면 많은 오버헤드가 발생한다. 따라서 단점을 해결하기 위해 persistant Connection을 제공한다. 

(HTTP/2, HTTP/3에서 더 많은 최적화 및 새로운 개념이 제안된다.)

 

HTTP연결의 두가지 방식 : non-Persistant vs Persistant HTTP

• non-Persistant 한 연결일 경우
  : 한 TCP 연결 당 request-response 쌍이 딱 한번만 가능하다. 따라서 각 request-response 마다 연결을 새로 설정해야한다.
  - 각 요청 당 TCP 연결을 위한 1 RTT + 파일 요청 1 RTT 필요
  - non-Persistant HTTP의 응답 받는 데 걸리는 시간 = 2 RTT + 파일 전송 시간
  > 하나의 파일을 전송할 때마다 2RTT가 소모되고, TCP 연결을 매번 맺어야하기 때문에 OS 오버헤드가 발생할 수 있다.
  
  
• Persistant 한 연결일 경우
  : 한 TCP 연결에서 여러번의 request-response 통신이 가능하다.
  - 서버는 응답 메세지를 보낸 이후 일정시간 동안 연결을 유지한다. Client에서 추가 메세지가 없는 경우 연결을 닫는다.
  - 연결이 유지되는 동안 client와 server는 HTTP 메세지를 주고받을 수 있다.
  - 모든 파일 수신을 위해 1 RTT 만 필요
• 11개의 파일을 전송하는 경우
  - non-Persistant HTTP 응답 받는 데 걸리는 시간 = 11 * (2 RTT + 파일 전송 시간)
  - Persistant HTTP 응답 받는 데 걸리는 시간 = 2 RTT + (11 * 파일 전송 시간)

→ Persistant로 response Time 과 TCP 연결을 위한 OS 오버헤드를 줄인다.

---

HTTP Message

HTTP 메세지는 요청 메시지와 응답 메세지로 구분된다.

 

Request Message

Client → Server 메세지

GET /main.html HTTP/1.1
Host: www.devuming.com
Connection: close
User-agent: Mozilla/5.0
Accept-language: kr

1. Request Line : 세가지 필드로 구성된다.  메소드 URL HTTP버전 
   - 메소드 종류 : GET, POST, HEAD, PUT, PUSH, DELETE → 웹서버의 동작을 결정한다.)
   - 요청대상 URL : (예제에서는 /main.html 에 데이터를 요청한다.)
2. Header Lines : 요청메세지의 부가 정보를 포함한다. '이름 : 값' 형태로 구성된다.
   - Host : 요청대상 Host 이름
   - Connection : HTTP 연결의 close 여부를 나타냄
   - User-agent : 사용자(클라이언트)의 브라우저 타입을 나타냄
   - Accept-language : 사용자가 선호하는 언어를 나타냄

HTTP Method

URI를 통해 리소스를 식별한 후, 리소스와 연계된 행위를 분리한다.

 

- EX) 회원 정보 관리를 한다고 할 때를 정의해보면

리소스 : 회원

행위 : 조회, 등록, 삭제, 변경

• 회원 목록 조회 → members
• 회원 조회 → members/{id}
• 회원 등록 → members/{id}
• 회원 수정 → members/{id}
• 회원 삭제 → members/{id} 라고 정의할 수 있다. => 하지만 구분이 어려움! → 메소드가 필요

HTTP 주요 메소드

1. GET : 리소스 조회

• 서버에 전달하고자 하는 쿼리를 전달
• 일반적으로 메세지 바디를 사용하지 않음

GET Request 로 id 가 100인 회원의 정보를 요청 → 서버는 DB에서 id=100인 회원의 정보를 응답해주는 예제

2. POST : 요청 데이터 처리 (주로 등록에 사용됨)

• 클라이언트로부터의 요청 데이터를 처리함
• 메세지 바디를 통해 서버로 요청 데이터를 전달함
• 주로 전달된 데이터를 등록, 처리하는데 사용함 (리소스 등록 : 회원가입, 주문, 게시판 글쓰기 등..)
• 프로세스 처리에도 쓰임 (주문 결제 완료-> 배달시작->배달완료)

POST 요청으로 회원을 등록하는 예제, 응답을 받은 서버는 id=101인 신규 리소스를 생성한다.

3. PUT : 리소스를 대체 (해당 리소스가 생성되지 않았다면, 생성함)

• 리소스가 있으면 대체 / 없으면 생성
• POST 와 차이점 : 클라이언트가 리소스 URI를 알고 있어야 한다. POST는 요청 생성해주기 때문에 몰라도 된다.
• 부분변경이 아니라 전체를 대체하기 때문에 부분 변경을 원한다면 PATCH를 사용해야한다.

예제1. id=101인 리소스의 정보를 대체한다.

예제2. "대체"이기 때문에 age 속성의 값만 전송하게 되면, 부분변경되지 않고, 전체 정보가 대체된다.

4. PATCH : 리소스 부분 변경

id=101인 회원 리소스를 부분 변경한다.

5. DELETE : 리소스 삭제

리소스 삭제 요청을 하면 서버는 리소스를 삭제한다.

• 서버에 전달하고자 하는 쿼리를 전달
• 일반적으로 메세지 바디를 사용하지 않음

* Client → Server 데이터 전송 시,

- 쿼리 파라미터를 통해 데이터 전송 : GET → 주로 검색 등의 조회에 사용된다.

- Body를 통한 데이터 전송 : POST, PUT, PATCH → 주로 회원가입, 상품 주문, 리소스 등록/변경 등에 사용된다.

---

Response Message

Server → Client

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 2450
Server: Apache/2.4.6 (CentOS)

(data....)

1. Status Line
   : HTTP 버전, 상태 코드, 상태 메시지로 이루어진다.
   
   Ex) HTTP/1.1 200 OK
   HTTP/1.1 → 사용하는 HTTP 버전
   200 → 상태코드 : 요청이 성공적으로 처리되었음
   OK → 상태 코드에 대한 간단한 설명
   
   
2. Header
   :  요청메세지의 부가 정보를 포함한다. '이름 : 값' 형태로 구성된다.
   - Content-Type : body의 MIME 타입
   - Content-Length : body 길이
   - Server : 서버 소프트웨어의 정보
   - .. 더 많은 헤더값이 있음
   
   
3. Body
   - 요청한 리소스를 포함한다. ex)HTML 파일 내용
   - Body 부분은 없을 수도 있다.

→ 회원 정보를 요청한 경우, Response의 Body 내용을 보면 회원 정보를 확인할 수 있다.

 

* 주요 상태 코드

• 2xx : 요청 정상 처리
  • 200 OK → 요청 성공
• 3xx: 요청 완료를 위한 추가 처리 필요 (EX: Redirect, 응답 메시지의 Location 헤더의 위치로 자동 Redirection 된다.)
  • 301 Moved Permanently → 리소스의 URI가 영구적으로 이동됨, 
• 4xx : 클라이언트 오류, 요청에 잘못된 문법등이 포함되어 서버가 요청을 처리할 수 없음 (오류의 원인은 클라이언트에 있음)
  • 400 Bad Request → 요청 구문, 메세지 등 오류
  • 404 Not Found → 요청 리소스가 서버에 없음, 또는 서버가 권한이 부족한 클라이언트의 리소스 접근에 대해 해당 리소스를 숨기고 싶을 때
• 5xx : 서버 문제로 오류 발생
  • 500 Internal Server Error → 서버 내부 문제로 오류 발생 

---

와 ! 이거 내용이 정말 많다 !

HTTP 버전 별 설명도 한번에 포스팅 할라 그랬는데 한번 끊어가는게 좋겠다... 다음 포스팅에서 만나요....🫥

긁적

 

 

- 

 

 

잘못된 정보가 있는 경우 댓글로 알려주시면 감사하겠습니다!