HTTP

출처 : 내일배움캠프 등

 

선수 개념 : OSI 7계층, TCP/IP, UDP

선수 학습 : IP 주소, 도메인 네임 시스템(DNS), 포트

 

체크리스트

1. HTTP에 대해 설명할 수 있는가?

2. HTTP의 통신 흐름을 설명할 수 있는가?

DNS, TCP/IP

DNS

*DNS 서버는 어떻게 IP 정보를 전송하는가?

https://aws.amazon.com/ko/route53/what-is-dns/

https://aws.amazon.com/ko/route53/what-is-dns/

1. 사용자가 웹 브라우저를 열어 주소 표시줄에 www.example.com을 입력
2. www.example.com에 대한 요청은 일반적으로 케이블 인터넷 공급업체, DSL 광대역 공급업체 또는 기업 네트워크 같은 인터넷 서비스 제공업체(ISP)가 관리하는 DNS 해석기로 라우팅
3. ISP의 DNS 해석기는 www.example.com에 대한 요청을 DNS 루트 이름 서버에 전달
4. ISP의 DNS 해석기는 www.example.com에 대한 요청을 .com 도메인의 TLD 이름 서버 중 하나에 다시 전달 후 example.com 도메인과 연관된 4개의 Amazon Route 53 이름 서버의 이름을 사용하여 요청에 응답
5. ISP의 DNS 해석기는 Amazon Route 53 이름 서버 하나를 선택해 www.example.com에 대한 요청을 해당 이름 서버에 전달
6. Amazon Route 53 이름 서버는 example.com 호스팅 영역에서 www.example.com 레코드를 찾아 웹 서버의 IP 주소 192.0.2.44 등 연관된 값을 받고 이 IP 주소를 DNS 해석기로 반환합니다.
7. ISP의 DNS 해석기가 마침내 사용자에게 필요한 IP 주소를 확보. 해석기는 이 값을 웹 브라우저로 반환합니다. 또한, DNS 해석기는 다음에 누군가가 example.com을 탐색할 때 좀 더 빠르게 응답할 수 있도록 사용자가 지정하는 일정 기간 example.com의 IP 주소를 캐싱(저장), Time to Live(TTL) 참조
8. 웹 브라우저는 DNS 해석기로부터 얻은 IP 주소로 www.example.com에 대한 요청을 전송합니다. 여기가 콘텐츠가 있는 곳으로, 예를 들어 웹 사이트 엔드포인트로 구성된 Amazon S3 버킷 또는 Amazon EC2 인스턴스에서 실행되는 웹 서버입니다.
9. 192.0.2.44에 있는 웹 서버 또는 그 밖의 리소스는 www.example.com의 웹 페이지를 웹 브라우저로 반환, 사용자에게 표시

패킷 교환 방식

vs 회선 통신 방식 : 정해진 경로로만 통신 ~ 트래픽 등에 의해 효율이 저하됨

데이터를 패킷 단위로 쪼개어 네트워크를 통해 전송, 각 패킷의 고유번호에 따라 최종 수신지에서 재결합

 *각 패킷은 전송 당시 가장 효율적인 경로로 통신하기 때문에 최적의 효율을 유지할 수 있다

TCP/IP

IP : 패킷을 가장 효율적으로 전송하기 위한 인터넷 프로토콜, 패킷 전달여부와 순서를 보장하지 않는다.

TCP : 패킷을 안전하게 전송하기 위한 전송 프로토콜

기법 -> 흐름제어/ 혼잡제어

https://gyoogle.dev/blog/computer-science/network/%ED%9D%90%EB%A6%84%EC%A0%9C%EC%96%B4%20&%20%ED%98%BC%EC%9E%A1%EC%A0%9C%EC%96%B4.html

흐름제어 : 송신측과 수신측의 데이터처리 속도의 차이를 조정 ~ 송신의 속도가 더 빠른 경우 문제발생(데이터 손실)

-> 송신측은 수신측의 데이터처리 속도에 맞춰 데이터를 전송해야 한다.

혼잡제어 : 한 라우터에 데이터가 몰릴 경우, 라우터는 데이터를 처리할 수 없게되고, 호스트는 데이터를 다른 라우터로 재전송하게 되는 오버플로우, 또는 데이터 손실이 발생할 수 있다.

~ 네트워크 내 패킷의 수가 과도하게 증가하는 현상을 혼잡이라고 한다. 이를 방지, 제거하는 기법을 혼잡제어라고 한다.

HTTP

클라이언트와 서버 간 자원을 교환하기 위한 TCP/IP 기반 통신 프로토콜

특징 :

단방향성 : 서버가 먼저 응답을 보낼 수 없다.

비연결성 : 클라이언트의 요청으로 서버와 연결 및 요청에 대한 데이터를 전송하고 나면 연결이 종료된다.

실시간 통신을 할 수 없다.

문제점 :

HTTP는 평문 통신이므로 도청 가능

통신 상대를 검증할 수 없어 위장 가능

완전성을 증명할 수 없어 변조 가능

 

cf) 실시간 채팅 등 : 웹소켓을 사용

 

**현재 가장 많이 쓰고있는 버전은 HTTP/1 (HTTP 1.1). HTTP/3(TCP/IP가 아닌 UDP기반)까지 발표되었다.

 

HTTP 메소드

주요 메소드 : GET, POST, PUT, PATCH, DELETE

안전 : 계속 호출해도 리소스를 변경하지 않음

멱등 : 동일 요청을 계속 호출한 것과 한번 요청한 결과가 같은 경우

캐시가능 : 응답 결과를 서버에 캐싱(임시저장)할 수 있는 메소드, 실제로는 구현이 어려워 GET과 HEAD에만 캐싱이 사용된다고 한다.

HTTP 상태코드

• 정의
  • 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주기 위한 정보
• 종류
  • 1xx (Informational): 요청이 수신되어 처리중
  • 2xx (Successful): 요청 정상 처리
    • 200 OK : 요청 성공
    • 201 Created : 요청 성공해서 새로운 리소스가 생성됨
    • 202 Accepted : 요청이 접수되었으나 처리가 완료되지 않았음
    • 204 No Content : 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음
  • 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요 (보통 리다이렉션처리)
    • 301 Moved Permanently : 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음
    • 302 Found : 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음
    • 303 See Other : 리다이렉트시 요청 메서드가 GET으로 변경
    • 304 Not Modified : 캐시를 목적으로 사용
    • 307 Temporary Redirect : 리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다.)
    • 308 Permanent Redirect : 리다이렉트시 요청 메서드와 본문 유지(처음 POST를 보내면 리다이렉트도 POST 유지)
  • 4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
    • 400 Bad Request : 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
    • 401 Unauthorized : 클라이언트가 해당 리소스에 대한 인증이 필요함
    • 403 Forbidden : 서버가 요청을 이해했지만 승인을 거부함
    • 404 Not Found : 요청 리소스를 찾을 수 없음
  • 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함

HTTP 통신흐름

1. 웹 브라우저에 사용자가 URL 입력

2. 도메인 네임 부분을 DNS 서버에 검색, DNS 서버에서 IP주소를 반환

3. 페이지 URL 정보와 반환된 IP주소를 포함하는 HTTP 요청 메세지를 생성 후 TCP 프로토콜을 사용해 해당 IP주소의 컴퓨터로 전송

4. 요청 메세지를 받은 컴퓨터는 웹 페이지 URL 정보 중 PATH와 HTTP 메소드에 맞는 코드 실행 후 응답 데이터 반환

5. 반환된 응답 데이터는 HTTP 프로토콜에 맞춰 HTTP 응답 데이터로 변환, 요청 컴퓨터로 TCP 프로토콜을 통해 반환

 

 cf) 브라우저 렌더링 과정

1. HTML, CSS 파일을 파싱해 DOM Tree, CSSOM Tree를 만든다.

2. 두 트리를 결합해 Rendering Tree 생성

3. Rendering Tree에서 각 노드의 위치와 크기 계산

4. 각 노드를 화면상의 실제 픽셀로 변환하고 레이어를 만든다.

5. 레이어를 합성하여 실제 화면에 나타낸다.

 

HTTP 메세지의 구조

https://developer.mozilla.org/ko/docs/Web/HTTP/Messages

1. Start line(응답 : Status line)

HTTP 상태 코드, HTTP 버전, 요청 타겟

2. Header

1) 요청 헤더 :

-General

-Request

-Entity

 

2) 응답 헤더 : 

-General

-Response

-Entity

 

3. 본문 :

요청 메세지 : 서버에 데이터를 전송하는 경우에만 생성됨(POST 등) ~ GET, DELETE 등의 리소스를 가져오는 요청에는 본문이 없다.

 

응답 메세지 : 상태 코드 201, 204의 경우, 응답 메세지 본문이 없다.