[1장] HTTP 개관

[eunbc]

[cloudwi]

장주영 정리
HTTP란 : HTTP (하이퍼텍스트 전송 프로토콜)

우리가 앞으로 배울 것들

• 얼마나 많은 클라이언트와 서버가 통신하는지
• 리소스(웹 콘턴츠)가 어디서 오는지
• 웹 트랜잭션이 어떻게 동작하는지
• HTTP 통신을 위해 사용하는 메시지의 형식
• HTTP 기저의 TCP 네트워크 전송
• 여러 종류의 HTTP 프로토콜
• 인터넷 곳곳에 설치된 사양한 HTTP 구성요소

HTTP: 인터넷의 멀티미디어 배달부

웹 서버로부터 이 대량의 정보를 빠르고, 간편하고, 정확하게 사람들의 PC에 설치된 웹브라우저로 옮겨준다.

HTTP는 신뢰성 있는 데이터 전송 프로토콜을 사용하기 때문에, 데이터가 지구 반대편에서 오더라도 전송 중 손상되거나 꼬이지 않음을 보장한다.

• GPT 한테 물어보기

  GPT 한테 물어보면 보장하지 않는다고 말하고 있어요.?

웹 클라이언트와 서버

리소스

가장 단순한 웹 리소스는 웹 서버 파일 시스템의 정적 파일이다.

하지만 정적 리소스, 동적 리소스 처럼 어떤 종류의 콘텐츠 소스도 리소스가 될 수 있다.

미디어 타입

인터넷은 수천 가지 데이터 타입을 다루기 때문에, HTTP는 웹에서 전송되는 객체 각각에 신중하게 MIME 타입이라는 데이터 포맷 라벨을 붙인다. MIME(Multiputpose Internet Mail Extensions, 다목적 인터넷 메일 확장)

URI

서버 리소스 이름은 통합 자원 식별자(uniform resource identifier), 혹은 URI로 불린다.

Scheme: 리소스에 접근하는 데 사용할 프로토콜. 웹에서는 http 또는 https를 사용

Host: 접근할 대상(서버)의 호스트 명

Path: 접근할 대상(서버)의 경로에 대한 상세 정보

URL

통합 자원 지시자(uniform resource locator, URL)는 리소스 식별자의 가장 흔한 형태다.

URN

유니폼 리소스 이름(uniform resource name, URN)

트랜잭션

트랜잭션은 요청명령과 응답결과로 구성되어 있다.

메서드

상태코드

웹페이지는 여러 객체로 이루어질 수 있다

메시지

TCP 커넥션

TCP(Transmission Control Protocol, 전송 제어 프로토콜)

TCP/IP

IP(Internet Protocol)

TCP/IP는 하드웨어에 구애받지 않는다

• 오류 없는 데이터 전송
• 순서에 맞는 전달
• 조각나지 않는 데이터 스트림

접속, IP 주소 그리고 포트번호

웹브라우저는 서버의 URL에서 호스트 명을 추출한다.

웹브라우저는 서버의 호스트 명을 IP로 변환한다.

웹브라우저는 URL에서 포트번호(있다면)를 추출한다.

웹브라우저는 웹 서버와 TCP 커넥션을 맺는다.

웹브라우저는 서버에 HTTP 요청을 보낸다.

서버는 웹브라우저는 HTTP 응답을 돌려준다.

커넥션이 닫히면, 웹브라우저는 문서를 보여준다.

텔넷을 이용한 실제 예제

프로토콜 버전

HTTP/0.9는 오직 GET 메서드만 지원하고,

HTTP 1.0+ 지속 커넥션, 가상 호스팅, 프락시 연결 지원 포함

웹의 구성요소

프락시

캐시

게이트웨이

터널

에이전트

프락시

캐시

게이트웨이

게이트웨이는 언제나 스스로가 리소스를 갖고 있는 진짜 서버인 것처럼 요청을 다룬다. 클라이언트는 자신이 게이트웨이와 통신하고 있음을 알아채지 못할 것이다.

터널

에이전트

[eunbc]

[1장] HTTP 개관

1. HTTP : 인터넷의 멀티미디어 배달부 (Hypertext Transfer Protocol)

1. 이미지, HTML 페이지, 텍스트 파일, 동영상 등 다양한 정보가 손상될 염려없이 전달되는 프로토콜 

2. 웹 클라이언트와 서버

1. 클라이언트는 서버에게 HTTP 요청을 보내고, 서버는 요청된 데이터를 HTTP 응답으로 돌려줌

3. 리소스 : 정적 파일, 동적 콘텐츠

1. 미디어 타입 
    1. 데이터 타입을 나타내기 위해 MIME 타입이라는 데이터 포맷 라벨을 붙임
    2. 예시) text/html, text/plain, image/jpeg, image/gif
2. URI
    1. uniform resource identifier, 통합 자원 식별자
    2. 리소스를 고유하게 식별하고 위치를 지정하는 역할
    3. URL, URN 두 가지 종류 포함
3. URL
    1. uniform resource locator
    2. URI의 가장 흔한 형태로, 리소스에 대한 구체적인 위치를 서술
    3. http://www.yahoo.com/images/logo.gif
    4. 통상적인 관례로 URI = URL
    5. 스킴 / 서버의 인터넷 주소 / 리소스 path 로 구성

4. URN
    1. uniform resource name
    2. 리소스의 위치에 관계없이 유일무이한 이름 역할을 함
    3. 실험중인 상태로 널리 채택되지 않음

4. 트랜잭션 : HTTP 요청과 응답

1. 메서드
    1. HTTP 요청 메시지에 포함되는 것으로, 서버에 어떤 동작을 취할 것인지 나타냄
    2. GET, PUT, DELETE, POST, HEAD
2. 상태코드
    1. HTTP 응답 메시지에 포함되는 것으로, 요청의 결과를 나타냄
    2. 200, 404, 302 
3. 웹페이지는 여러 객체로 이루어질 수 있다
    1. 웹페이지는 리소스의 모음이다
    2. 애플리케이션은 보통 하나의 작업을 수행하기 위해 여러 HTTP 트랜잭션을 수행한다

6. 메시지

1. 간단한 메시지의 예
    1. 이진 형식이 아닌 일반 텍스트이기 때문에 사람이 읽고 쓰기 쉬움
        1. 시작줄 : 무엇을 해야하는지 / 무슨 일이 일어났는지 표시
        2. 헤더 : 쌍점(:) 으로 구분된 이름과 값으로 구성, 빈 줄로 끝남
        3. 본문 : 문자열 이외에도 이진 데이터(이미지, 파일) 포함 가능
    2. 

그림 출처

7. TCP 커넥션

1. TCP/IP
    1. HTTP는 TCP(Transmission Control Protocol) 커넥션을 통해 전송된다
    2. TCP는 오류 없는 데이터 전송, 순서에 맞는 전달, 조각나지 않는 데이터 스트림을 제공한다
2. 접속, IP 주소 그리고 포트번호
    1. HTTP 메시지를 보내기 전에, IP 주소와 포트번호를 사용해 클라이언트와 서버 사이에 TCP/IP 커넥션을 맺어야 함
    2. http://207.200.83.29:80/index.html
    4. http://www.netscape.com/index.html
    5. http://www.netscape.com 같은 호스트 명은 DNS를 통해 IP로 변환되고, 포트번호가 없다면 HTTP는 기본 포트번호가 80임

8. 프로토콜 버전

1. HTTP/0.9 : 1991년에 사용, 심각한 디자인 결함이 있으며 GET 메서드만 지원
2. HTTP/1.0 : 처음으로 널리 쓰이기 시작, www의 대세 
3. HTTP/1.0+ : www의 성공으로 기능 추가, keep-alive 커넥션 
4. HTTP/1.1 : 설계 결함 교정, 성능 최적화, 현재의 HTTP 버전
6. HTTP/2.0 : 1.1의 성능 문제를 개선하기 위해 Google SPDY를 기반으로 구현, 2022년 1월 기준 전체 웹사이트의 46.9% 사용
7. HTTP/3.0 : QUIC를 통한 HTTP, 2022년 10월 기준 전체 웹사이트의 26%
8. [HTTP의 진화](https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP)

9. 웹의 구성요소

1. 프락시 
    1. 클라이언트의 모든 HTTP 요청을 받아 서버에 전달해줌. 사용자를 대신해서 서버에 접근
    2. 주로 보안을 위해 사용됨
    3. 다운로드시 바이러스 검출, 초등학교 학생들에게서 성인 콘텐츠 차단
2. 캐시 : 많이 찾는 웹페이지를 클라이언트 가까이에 보관하는 HTTP 창고
3. 게이트웨이 : 다른 서버들의 중개자로 동작하는 서버, 주로 HTTP 트래픽을 다른 프로토콜(ex. FTP)로 변환하기 위해 사용 
4. 터널 : 단순히 HTTP 통신을 전달하기만 하는 특별한 프락시, 대표적인 예시로는 SSL 트래픽을 HTTP 커넥션으로 전송하여 웹 트래픽만 허용하는 사내 방화벽을 통과시키는 사례가 있음 
5. 에이전트 : 자동화된 HTTP 요청을 만드는 준지능적 웹클라이언트, 사람의 통제 없이 스스로 웹을 돌아다니며 콘텐츠를 받아와 유용한 웹 콘텐츠 보관소를 만든다

[annahxxl]

HTTP

• 신뢰성 있는 데이터 전송 프로토콜(TCP)을 사용한다

웹 클라이언트와 서버

• 클라이언트는 서버에게 http 요청을 보내고 서버는 요청된 데이터를 http 응답으로 돌려준다
• http 클라이언트와 http 서버는 www의 기본 요소이다

리소스

• 웹 리소스는 정적 콘텐츠와 동적 콘텐츠가 있다
  • 정적 콘텐츠: text 파일, html 파일, jpeg 이미지 파일 •••
  • 동적 콘텐츠: 누구인지, 어떤 정보를 요청했는지, 몇 시인지에 따라 다른 콘텐츠 생성 •••

미디어 타입

• 웹 서버는 모든 http 객체 데이터에 MIME 타입을 붙인다
• 웹브라우저는 서버로부터 객체를 돌려받을 때, 다룰 수 있는 객체인지 MIME 타입을 통해 확인한다
• MIME 타입은 사선(/)으로 구분된 주 타입과 부 타입으로 이루어진 문자열 라벨이다
  • HTML로 작성된 텍스트 문서 → text/html
  • plain ASCII 텍스트 문서 → text
  • JPEG 이미지 → image/jpeg

URI

• 통합 자원 식별자
• 정보 리소스를 고유하게 식별하고 위치를 지정할 수 있다
• URL과 URN으로 나눌 수 있다

URL

• 통합 자원 지시자
• 특정 서버의 한 리소스에 대한 구체적인 위치를 서술한다
• 세 부분으로 이루어져 있다
  • 리소스에 접근하기 위해 사용되는 프로토콜 (http://) - 스킴
  • 서버의 인터넷 주소 (www.google.com)
  • 웹 서버의 리소스 (/images/sampe.gif)

URN

• 유니폼 리소스 이름
• 위치에 영향 받지 않는 유일무이한 이름 역할을 한다
• 리소스를 여기저기로 옮기더라도, 여러 종류의 네트워크 프로토콜로 접근해도 문제없이 동작한다
• 아직 채택되지는 않았으나 전망은 밝다

트랜잭션

• 요청과 응답 메시지로 구성되어 있다

메서드

• 모든 http 요청 메시지는 한 개의 메서드를 갖는다
• 메서드는 서버에게 어떤 동작이 취해져야 하는지 말해준다

상태 코드

• 모든 http 응답 메시지는 상태 코드와 함께 반환된다
• 상태 코드는 클라이언트에게 요청이 성공했는지 아니면 추가 조치가 필요한지 알려주는 세 자리 숫자다

웹페이지는 여러 객체로 이루어질 수 있다

• 애플리케이션은 보통 하나의 작업을 수행하기 위해 여러 http 트랜잭션을 수행한다
• 웹페이지는 보통 하나의 리소스가 아닌 리소스의 모음이다

메시지

• 시작줄, 헤더, 본문 세 부분으로 이루어져 있다
  • 시작줄: 요청은 무엇을 해야 하는지, 응답은 무슨 일이 있어났는지 나타낸다
  • 헤더: 쌍점(:)으로 구분되어 있는 하나의 키:값 으로 구성되고 마지막은 빈 줄로 끝난다
  • 본문: 어떤 종류의 데이터든 들어갈 수 있다

TCP 커넥션

TCP/IP

• http는 애플리케이션 계층 프로토콜이고 네트워크 통신은 TCP/IP에게 맡긴다
• TCP는 다음을 제공한다
  • 오류 없는 데이터 전송
  • 순서에 맞는 전달
  • 조각나지 않는 데이터 스트림

접속, IP 주소 그리고 포트번호

• http 클라이언트가 서버에 메시지를 전송할 수 있게 되기 전에, IP주소와 포트번호를 사용해 클라이언트와 서버 사이에 TCP/IP 커넥션을 맺어야 한다
• URL을 이용해 IP주소와 포트번호를 알아낸다
  1. 호스트 명은 DNS를 통해 IP로 변환된다
  2. http URL에 포트번호가 빠진 경우에는 기본값 80이라고 가정하면 된다

[kimday0326]

HTTP?

추상적으로 설명하자면, HTTP는 인터넷의 정보들을 전달해주는 배달부와 같다. 수많은 멀티미디어 정보들을 빠르고, 간편하고, 정확하게 전달해줄뿐만 아니라, 전달되는 정보의 무결성을 보장해준다.

웹 클라이언트와 서버

• 인터넷에 존재하는 수많은 멀티미디어 정보들을 우리는 웹 콘텐츠라고 한다.
• 웹 콘텐츠는 웹 서버에 존재하며, 웹 클라이언트에 요청에 따라 콘텐츠를 전송(응답)한다.

리소스

• 웹 리소스는 웹 콘텐츠의 원천이다. (웹 리소스 > 웹 콘텐츠)
• 정적 파일일수도, 동적으로 콘텐츠를 생성하는 프로그램이 될 수도 있다.

미디어 타입

• 인터넷에는 수천가지 데이터타입이 존재하므로, HTTP에서는 MIME 데이터 포맷 라벨을 활용한다.
• MIME은 기존에 서로 다른 메일 시스템 간의 통신을 위해 생겨났지만, 현재는 HTTP에서도 이를 사용하고 있다.
• 웹 브라우저는 서버로부터 받아온 데이터(객체)의 MIME 타입을 보고 후행 동작을 실행한다.

MIME은 주 타입(prior type)과 서브 타입(specific subtype)이 / 문자로 구분되어있는 문자열이다.
text/html, text/plain, image/gif, application/json ... 수백 가지가 넘게 존재한다.

URI / URL / URN

URI(Uniform Resource Identifier) 는 URL과 URN을 포함하는 개념이며, 인터넷 상의 자원을 식별하는 "식별자"이다.

• URL(locator): 자원의 구체적인 위치를 나타내는 지시자. 스킴(Scheme), 주소, 리소스로 구성된다. (뒤에서 추가 설명)
• URN(name): 위치에 영향을 받지 않는 자원의 이름. 아직 연구중이며, 널리 채택되지 않았다.
  일반적으로 URI와 URL은 같은 의미로 사용된다.

트랜잭션

요청과 응답으로 구성된 하나의 통신 단위

HTTP 메서드와 상태코드

요청은 HTTP 메서드와 함께 전달되고, 응답 메세지는 상태코드와 함께 반환된다.

웹페이지는 여러 번의 트랜잭션을 통해 가져온 리소스의 모음이다.

메시지

HTTP 메시지(응답, 요청)은 세 부분으로 이루어진다.

1. 시작줄
   -> 요청이라면 무엇을 해야하는지, 응답이라면 무슨일이 일어났는지를 담는다.
2. 헤더
   -> 0개 이상의 헤더필드. 쌍점(:)으로 구분되어있는 하나의 이름과 값으로 구분된다.
3. 본문
   -> 어떤 종류의 데이터든 들어갈 수 있으며, 필요에 따라 포함한다.

TCP 커넥션

TCP/IP

HTTP가 사용하는 대중적인 인터넷 전송 프로토콜
TCP는 오류 없는 전송, 순서 보장, 조각나지 않는 데이터 스트림을 제공한다.

IP주소와 포트번호

HTTP 클라이언트가 메시지를 전송하기 전에, 클라이언트와 서버는 IP주소와 포트번호를 이용해 TCP/IP 커넥션을 맺어야한다. IP주소와 포트번호는 URL을 통해 알아낼 수 있다.

• IP주소: 호스트를 구분하기 위해 사용된다. IP주소 대신 도메인 네임(호스트 네임)을 사용하기도 한다.
• 포트 번호: 해당 호스트에서 실행중인 프로그램(프로세스)를 구분하기 위해 사용된다. URL에 포트 번호가 생략된 경우, 기본값은 80이라고 가정하면 된다.

[park0jae]

웹 클라이언트와 서버

---

• 웹 브라우저는 서버에게 HTTP 객체를 요청하고, 사용자의 화면에 보여준다.
• ex) “http://www.oreilly.com/index.html” 페이지를 열어볼 때, HTTP 요청을 www.oreilly.com 서버로 보냄
• 서버는 요청을 받고 /index.html 를 찾는데 성공하면, 그것의 타입과 길이 등의 정보와 함께 HTTP 응답에 실어 클라이언트에게 보냄

리소스

---

• 웹 서버는 웹 리소스를 관리하고 제공한다.
• 리소스는 반드시 정적 파일이어야 할 필요는 없고, 요청에 따라 콘텐츠를 생산하는 프로그램이 될 수도 있다.
• 동적 콘텐츠 리소스는 사용자가 누구인지, 어떤 정보를 요청했는지, 몇시인지에 따라 동적으로 콘텐츠를 생성한다.

미디어 타입

---

• HTTP는 웹에서 전송되는 객체 각각에 신중하게 MIME 타입이라는 데이터 포맷 라벨을 붙인다.
• MIME(Multipurpose Internet Mail Extensions, 다목적 인터넷 메일 확장)
• MIME 타입은 사선(/)으로 구분된 주 타입(primary object type)과 부 타입(specific subtype)으로 이루어진 문자열 라벨이다.
  • HTML로 작성된 텍스트 문서 : text/html
  • plain ASCII 텍스트 문서 : text/plain
  • JPEG 이미지 : image/jpeg
  • GIF 이미지 : image/gif

URI

---

• 서버 리소스 이름은 통합 자원 식별자(Uniform Resource Identifier) , 혹은 URI로 불린다.
• ‘죠의 컴퓨터 가게’의 웹 서버에 있는 이미지 리소스에 대한 URI라면 ?

<aside> 💡 “http://www.joes-hardware.com/specials/saw-blade.gif

→ www.joes-hardware.com으로 이동해서 /specials/saw-blade.gif라고 불리는 리소스를 가져오란 의미

</aside>

URL

---

• 통합 자원 지시자(Uniform Resource Locator, URL)는 리소스 식별자의 가장 흔한 형태
• 특정 서버의 한 리소스에 대한 구체적인 위치를 서술한다.
• URL은 리소스가 정확히 어디에 있고 어떻게 접근할 수 있는지 분명히 알려준다.
• 통상적으로 URI → URL로 칭한다.

부분	명칭	설명
file://, http://, https://	scheme	통신 프로토콜
127.0.0.1, www.google.com	hosts	웹 페이지, 이미지, 동영상 등의 파일이 위치한 웹 서버, 도메인 또는 IP
:80, :443, :3000	port	웹 서버에 접속하기 위한 통로
/search, /Users/username/Desktop	url-path	웹 서버의 루트 디렉토리로부터 웹 페이지, 이미지, 동영상 등의 파일이 위치까지의 경로
q=JavaScript	query	웹 서버에 전달하는 추가 질문

상태 코드 (자세한 내용은 뒷 장에서 알아보자)

---

• 1xx (Information) : 요청이 수신되어 처리중이며, 계속해서 프로세스를 진행한다.
• 2xx (Successful) : 요청을 성공적으로 수신했으며, 정상 처리 되었다.
• 3xx (Redirection) : 요청을 완료하려면 추가적인 행동(리소스)이 필요하다.
• 4xx (Client Error) : 클라이언트 오류, 잘못된 문법/요청 등으로 서버가요청을 수행할 수 없다.
• 5xx(Server Error) : 서버가 정상 요청을 처리하지 못함

웹 페이지는 여러 객체로 이루어질 수 있다.

• 애플리케이션은 보통 하나의 작업을 수행하기 위해 여러 HTTP 트랜잭션을 수행한다.
  • 페이지 레이아웃을 서술하는 HTML ‘뼈대’를 한 번의 트랜잭션으로 가져온다.
  • 이후, 첨부된 이미지나 그래픽 조각, 자바 애플릿 등을 가져오기 위해 추가로 HTTP 트랜잭션을 수행한다.

메시지

• 웹 클라이언트에서 웹 서버로 보낸 HTTP 메시지를 요청 메시지라고 부른다.
• 서버에서 클라이언트로 가는 메시지는 응답 메시지라고 부른다.
• 시작줄 / 헤더 / 본문으로 이루어짐

1. 시작줄 : 메시지의 첫 줄로 요청이라면 무엇을 해야 하는지, 응답이라면 무슨 일이 일어났는지를 나타냄

HTTP/1.0 200 OK

2. 헤더 : 헤더 필드는 쌍점(:)으로 구분되어 있는 하나의 이름과 값으로 구성

Content-type: text/plain
Content-length: 19

3. 본문 : 요청의 본문은 웹 서버로 데이터를 실어 보내며, 응답의 본문은 클라이언트로 데이터를 반환한다.

안녕하세요. 메시지입니다.

TCP 커넥션

• HTTP는 애플리케이션 계층 프로토콜이다.
• HTTP는 네트워크 통신의 핵심적인 세부사항에 대해 신경 쓰지 않는다.
• 대신 대중적이고 신뢰성 있는 인터넷 전송 프로토콜인 TCP/IP에게 맡긴다.
  • 오류 없는 데이터 전송
  • 순서에 맞는 전달(데이터는 언제나 보낸 순서대로 도착)
  • 조각나지 않는 데이터 스트림(언제든 어떤 크기로든 보낼 수 있다)

요청의 흐름

• 웹 브라우저는 서버의 URL에서 호스트명을 추출한다.
• 웹 브라우저는 서버의 호스트 명을 IP로 변환한다.
• 웹 브라우저는 URL에서 포트번호를 추출한다.
• 웹 브라우저는 웹 서버와 TCP 커넥션을 맺는다.
• 웹 브라우저는 서버에 HTTP 요청을 보낸다.
• 서버는 웹 브라우저에 HTTP 응답을 돌려준다.
• 커넥션이 닫히면, 웹 브라우저는 문서를 보여준다.

프로토콜 버전

• HTTP/0.9 : 결함이 많고 구식 클라이언트만 사용 가능, MIME이나 HTTP 헤더 지원 XXXX
• HTTP/1.0 : 널리 쓰이기 시작한 HTTP 버전, 결코 잘 정의된 명세는 아니며 잘 동작하는 용례들의 모음에 가깝다.
• HTTP/1.1 : HTTP 설계의 구조적 결함 교정, 두드러진 성능 최적화, 잘못된 기능 제거에 집중
• HTTP/2.0 : HTTP/1.1 성능 문제를 개선하기 위해 구글의 SPDY 프로토콜을 기반으로 설계가 진행 중인 프로토콜

<aside> 💡 간단히 정리해본 문제점과 발전된 부분

HTTP 1.0 : 매 요청마다 연결/해제의 과정이 발생하여 오버헤드가 발생했고 시간의 지연이 이루어졌었습니다. HTTP 1.1 : Persistent connection 방식과 Pipelining 방식 도입

• Persistent connection : 연결 지속 시간 설정 → 연결/해제 과정 없지만 TCP 특성상 요청 후 응답을 기다려야함
• Pipelining : 이러한 문제를 개선하고자 등장함, 응답에 의존하지 않고 요청을 보냄

→ 그러나 여기서도 문제점이 존재했다. Pipelining은 응답은 순서대로 보내주기 때문에 처리시간이 긴 요청에 응답을 기다리는 HOL Blocking 문제가 발생

HTTP 2.0 : 리소스 간 우선순위를 설정하여 HOL Blocking 문제를 해결

</aside>

→ 오늘날의 HTTP 버전은 1.1을 가장 많이 사용한다.

웹의 구성요소

• 프록시 : 클라이언트와 서버 사이에 위치한 HTTP 중재자
• 캐시 : 많이 찾는 웹 페이지를 클라이언트 가까이에 보관하는 HTTP 창고
• 게이트웨이 : 다른 애플리케이션과 연결된 특별한 웹 서버
• 터널 : 단순히 HTTP 통신을 전달하기만 하는 특별한 프락시
  • 터널을 이용하여 HTTP 커넥션을 통해서 HTTP가 아닌 트래픽을 전송할 수 있고 다른 프로토콜을 HTTP 위에 올릴 수 있다
• 에이전트 : 사용자를 위해 HTTP 요청을 만들어주는 클라이언트 프로그램 (= 웹 브라우저)

[ 프록시와 게이트웨이의 차이 ]

• 프록시는 중간에서 요청을 받아서 전달하고, 응답도 받아서 클라이언트에 전달하는데 네트워크 캐싱과 보안점 역할 (방화벽)을 하는데 목적이 있다.
• 게이트웨이는 프록시와 유사하게 특정 네트워크에서 다른 네트워크로 이동하기 위해 거쳐야 하는 필수 지점이다. 게이트웨이는 리소스와 어플리케이션을 연결하는데, HTTP 트래픽을 변환해서 다른 프로토콜로 통신한다. 예를 들어 실시간, 스트리밍 동영상의 경우에는 HTTP 프로토콜을 RTP 프로토콜로 변환해서 리소스를 받아온다.

→ 추가로 Proxy 서버는 허용된 네트워크만 통과할 수 있지만, 게이트웨이에서는 필터링을 거치지 않는다.

[KarmaPol]

HTTP

신뢰성 있는 데이터 전송 프로토콜을 사용해 인터넷 애플리케이션 개발자가 통신 결함에 대해 고려하지 않아도 됨

웹 클라이언트와 서버

웹 서버는 HTTP 요청을 받아, 요청 받은 객체를 찾고, 성공 시 그것의 정보를 HTTP 응답에 실어 클라이언트에 보낸다

리소스

웹 서버는 웹 리소스를 관리하고 제공
리소스는 정적파일(텍스트, HTML, 워드, 이미지, 동영상 등)과 동적 컨텐츠
동적 컨텐츠는 사용자 요청에 따라 다른 컨텐츠를 생성

미디어 타입

웹 서버는 모든 HTTP 객체에 MIME 미디어 타입 붙임

• HTML - text/html
• JPEG - image/jpeg

URI

인터넷의 우편물 주소

URL

URI의 가장 흔한 형태
리소스가 정확히 어디에 있고 어떻게 접근하는 지
프로토콜 + 인터넷 주소 + 리소스

URN

위치에 영향 받지 않는 유일무이한 리소스 이름
ex) 인터넷 표준 문서 'RFC 2141'

트랜잭션

HTTP 트랜잭션은 요청 + 응답 결과의 묶음

메서드

• Get
• Put
• Delete
• Post
• Head - 리소스 응답에서 http 헤더 부분만 보내라

상태 코드

요청 성공 여부, 추가 조치 필요 여부를 상태 코드로 클라이언트에게 알려줌

웹페이지는 여러 객체로 구성

하나의 작업을 수행하기 위해 여러 HTTP 트랜잭션을 수행
첨부된 이미지, 그래픽 조각들을 가져오기 위해 여러 트랜잭션을 한 페이지에서 실행

메시지

메시지 구성

• 시작줄
  GET /test HTTP 1.0
• 헤더
  Accept : text/*
• 본문

TCP 커넥션

TCP / IP

HTTP 프로토콜 - 애플리케이션 계층
TCP / IP 프로토콜 - 전송, 네트워크 계층
신뢰성 있는 네트워크 의사소통 보장, 패킷 손상, 순서 뒤바뀜 X

접속, IP 주소, 포트번호

URL을 통해 서버 주소와 포트 번호를 알아낼 수 있다
글자로 된 도메인 이름인 경우, DNS 서버와 통신해 IP 주소를 알아낸다

프로토콜 버전

• HTTP/0.9
• HTTP/1.0
• HTTP/1.0+
• HTTP/1.1
  구조적 결함 교정, 성능 최적화로 현재의 HTTP 버전
• HTTP/2.0
  차세대 프로토콜

웹 구성 요소

프락시

클라이언트와 서버 사이에서 사용자를 대신해 서버에 접근
트래픽 흐름 속에서 신뢰할 만한 중개자 역할, 요청과 응답 필터링

캐시

자주 찾는 것의 사본을 저장하는 특별한 프락시 서버

게이트웨이

HTTP 트래픽을 다른 프로토콜로 변환
다른 서버들의 중개자 역할

터널

비 HTTP 데이터를 열어보지 않고 그대로 전달

에이전트

HTTP 요청을 만들어 주는 클라이언트 프로그램
웹 브라우저, 스파이더, 웹 로봇

[byulcode]

1. TCP 는 어떻게 신뢰성 있는 통신을 제공하는가?

TCP는 클라이언트와 서버 간에 신뢰성 있는 데이터 교환(오류 없는 데이터 전송, 순서 보장, 조각나지 않는 데이터 스트림)을 보장하는데, 이게 가능한 이유가 뭘까?

• TCP는 헤더에 일련 번호(Sequence Number)와 응답번호(ACK Number)를 포함하여 IP에 전송한다. ⇒ 순서 보장!

  • Sequence Number : 송신자가 지정하는 순서 번호, 전송되는 바이트 수를 기준으로 증가
  • ACK Number : 수신 프로세스가 제대로 수신한 바이트의 수를 응답하기 위해 사용. (Sequence Number +1)

• 연결시 3-way handshake 방식을 사용

  1. 클라이언트가 서버에 연결 요청(SYN)
  2. 서버가 요청 수락/응답, 클라이언트에 연결 요청 (SYN + ACK)
  3. 클라이언트가 서버에게 연결 수락/응답 (ACK)

  ⇒ 상호 동의, 일련번호 및 순서, 신뢰성, 바이트 스트림 전송 보장!

  참조

  [https://velog.io/@hidaehyunlee/TCP-와-UDP-의-차이](https://velog.io/@hidaehyunlee/TCP-%EC%99%80-UDP-%EC%9D%98-%EC%B0%A8%EC%9D%B4)

  [https://velog.io/@ragnarok_code/Network-TCP-프로토콜-연결종료-과정](https://velog.io/@ragnarok_code/Network-TCP-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C-%EC%97%B0%EA%B2%B0%EC%A2%85%EB%A3%8C-%EA%B3%BC%EC%A0%95)

  https://mangkyu.tistory.com/15

2. keep-alive 커넥션이란?

“Keep-Alive”는 HTTP 통신에서 사용되는 기능으로, 지속적인 연결(Persistent Connection)을 유지하는 기법 중 하나이다. HTTP1.0+부터 지원되었으며, HTTP/1.1부터는 기본적으로 활성화되어 있다.

하나의 TCP connection을 활용해 여러 개의 HTTP 요청/응답을 주고받을 수 있게 해준다. 기존에는 한 요청에 응답할 때마다 connection을 close하도록 설정돼있었는데, keep-alive 옵션은 connection을 유지할 수 있게 해준다.

Persistent Connection이란?

• 여러 HTTP 요청과 응답을 하나의 TCP 연결에서 지속적으로 처리하는 메커니즘. (일반적으로 HTTP는 각각의 요청과 응답 사이에 새로운 TCP 연결을 맺음)
• 서버에 연속적으로 동일한 클라이언트가 여러 요청을 보낼 때, 모든 요청에 TCP 3-way handshake를 맺을 필요가 없어져 네트워크 비용, 지연 시간, 오버헤드가 감소한다.

참조

https://etloveguitar.tistory.com/137