HTTP에 대해

HTTP란

---

• HTTP는 Hypertext Transfer Protocol의 약자입니다. 
• HTTP는 신뢰성있는 데이터 전송 프로토콜을 사용하기 때문에, 데이터 전송 중 파손되거나, 중복되거나, 왜곡되는 것을 걱정하지 않아도 됩니다.

 

💡 클라이언트와 서버

 

• 클라이언트(브라우저)는 서버에게 HTTP 요청을 보내고, 서버는 그에 맞는 데이터를 HTTP 응답으로 반환해줍니다.

 

리소스

---

💡 미디어 타입

 

• 인터넷은 수천가지의 데이터 타입을 다루기 때문에 HTTP는 웹에서 전송되는 객체에 MIME 타입이라는 데이터 포맷 라벨을 붙입니다.
• 웹 서버는 모든 HTTP 객체 데이터에 MIME 데이터 포맷 라벨을 붙입니다. 웹 브라우저는 서버로부터 응답값을 받았을 때 이 웹 브라우저가 다룰 수 있는 MIME 타입인지 확인하게 됩니다.
• MIME 타입은 /로 구분되며 주 타입과 부 타입으로 구성됩니다. 예를들어 아래 사진을 보면 content-type: text/plain; charset=UTF-8 을 확인할 수 있습니다.

💡 URI

 

• Uniform Resource Identifier의 약자인 URI는 통합 자원 식별자 입니다.
• 하위 개념으로는 URL과 URN이 있습니다.

출처: https://gguldh.tistory.com/25

💡 URL

 

• Uniform Resource Locator의 약자인 URL은 통합 자원의 위치를 나타내기 위한 규약 입니다.
• 오늘날의 대부분 URI는 URL입니다.
• URL은 세 부분으로 이루어져 있습니다.
  • 첫번째 부분은 scheme이라 불리는 프로토콜입니다. 여기에는 http, https 기타 등이 있습니다.
  • 두번째 부분은 서버의 인터넷 주소 즉 도메인을 의미합니다. 예를들어 www.naver.com이 있습니다.
  • 세번째 부분은 서버의 리소스를 가리킵니다. 예를들어 /auth/login이 있습니다.

 

💡 URN

 

• Uniform Resource Name의 약자인 URN은 콘텐츠를 이루는 하나의 자원에 대해 해당 자원의 위치에 영향을 받지 않는 유일무이한 이름 역할을 합니다.
• 자원의 이름이 변하지 않는 한 여러 네트워크에서 접속해도 문제가 없습니다.

 

즉, URL은 리소스가 어디 있는지 설명해서 리소스를 식별합니다. 반면 URN은 현재 그 리소스가 어디에 존재하든 상관없이 그 이름만으로 리소스를 식별합니다.

 

TCP 커넥션

---

💡 TCP/IP

 

• HTTP는 네트워크 통신의 핵심적인 세부사항에 대해서는 신경쓰지 않습니다. 대신 대중적이고 신뢰성 있는 인터넷 전송 프로토콜인 TCP/IP에게 맡깁니다.
• TCP/IP는 오류가 없고, 순서를 보장하며, 언제든 어떤 크기로든 보낼 수 있습니다.
• OSI 7 Layer에서 TCP/IP는 트랜스 포트의 계층에 속합니다. 또한 TCP/IP는 각 네트워크와 하드웨어의 특성을 숨기고 어떤 종류의 컴퓨터나 네트워크든 서로 신뢰성 있는 통신을 하게 해줍니다.

💡 커넥션 과정

 

• 프로토콜과 도메인, 포트 번호를 사용하여 클라이언트와 서버 사이에 TCP/IP 커넥션을 맺어야 합니다.
• TCP/IP 커넥션 과정 살펴보기

과정

 

1. 웹 브라우저는 서버의 URL에서 도메인명을 추출합니다.
2. 웹 브라우저는 서버의 도메인명을 IP로 변환합니다.
3. 웹 브라우저는 포트번호가 있다면 추출합니다.
4. 웹 브라우저는 서버와 TCP 커넥션을 맺습니다.
5. 웹 브라우저는 서버에게 HTTP 요청을 보냅니다.
6. 서버는 웹 브라우저에게 HTTP 응답을 보냅니다.
7. 커넥션이 닫히면, 웹 브라우저는 서버로부터 받은 응답값을 사용하여 보여줍니다.

 

프로토콜 버전

---

💡 HTTP/0.9

 

• HTTP/0.9는 HTTP의 가장 초기 버전입니다.
• GET 메서드만 지원합니다.
• 멀티 미디어 콘텐츠에 대한 MIME 타입이나, HTTP 헤더, 버전 번호는 지원하지 않습니다.
• 응답은 간단한 HTML 객체를 받아오기 위해 만들어졌습니다.
• 상태/오류 코드가 없습니다.

 

💡 HTTP/1.0

 

• 버전 번호, HTTP 헤더, 멀티 미디어 객체 처리를 추가하였습니다.
• GET, POST, HEAD 메서드를 지원합니다.

 

💡 HTTP/1.1

 

• HTTP/1.1은 1997년에 도입되었으며, 기존 HTTP 설계의 구조적 결함 교정, 성능 최적화, 잘못된 기능 제거에 집중하였습니다.
• HTTP/0.9와 HTTP/1.0은 요청에  대한 응답을 받으면 연결이 바로 종료되었지만 HTTP/1.1은 오래 지속되는 keep-alive 커넥션을 지원하였습니다.
• GET, POST, HEAD, PUT, DELETE, TRACE, OPTIONS 등의 메서드를 지원합니다.
• 파이프 라이닝, 콘텐츠 협상, 캐시 제어를 도입하였습니다.

 

• 파이프 라이닝
  • 첫 번째 요청에 대한 응답을 받기 전에 두 번째 요청을 전송할 수 있습니다.

 

• 콘텐츠 협상
  • 클라이언트와 서버 사이에서 어떠한 타입의 리소스(자원)를 교환할 것인지 정하는 방법입니다.

 

• 캐시 제어
  • 요청 및 응답에서 캐시 정책을 수행합니다.

 

웹의 구성요소

---

💡 프락시

 

• 클라이언트와 서버 사이에 위치하여, 클라이언트의 모든 HTTP 요청을 받아 서버에 전달합니다.
• 프락시는 주로 보안을 위해 사용됩니다. 모든 웹 트래픽 흐름 속에서 신뢰할 만한 중개자 역할을 수행합니다.
• 프락시는 요청과 응답을 필터링하는데 예를들어 무엇가를 다운 받을 때 바이러스를 검출한다거나 미성년자에게서 성인 콘텐츠를 차단합니다.

💡 캐시

 

• 웹 캐시와 캐시 프락시는 자신을 거쳐가는 문서들 중 자주 찾는 것의 사본을 저장해두는 특별한 종류의 HTTP 프락시 서버입니다.
• HTTP는 캐시를 효율적으로 동작하게 하고, 캐시된 콘텐츠를 최신 버전으로 유지하면서 동시에 프라이버시도 보호하기 위한 많은 기능을 정의하고 있습니다.

 

💡 게이트 웨이

 

• 게이트 웨이는 다른 서버들의 중개자로 동작하는 특별한 서버입니다. 
• 게이트 웨이는 주로 HTTP 트래픽을 다른 프로토콜로 변환하기 위해 사용됩니다.
• 게이트 웨이는 언제나 스스로가 리소스를 가지고 있는 진짜 서버인거처럼 요청을 다룹니다. 클라이언트는 자신이 게이트 웨이와 통신하고 있음을 알아채지 못합니다.

 

💡 터널

 

• 터널은 두 커넥션 사이에서 raw 데이터를 열어보지 않고 그대로 전달해주는 HTTP 애플리케이션입니다.
• HTTP 터널은 비 HTTP 데이터를 하나 이상의 HTTP 연결을 통해 그대로 전송해주기 위해 사용됩니다.

 

 

참고자료

• https://www.elancer.co.kr/blog/view?seq=74
• https://developer-talk.tistory.com/388