[http 완벽 가이드] 1장 HTTP 개관

이 내용은 http 완변 가이드란 책을 읽고 정리한 내용입니다.

 

더 자세한 내용이 궁금하시면 책을 직접 읽어보시는 걸 추천합니다.

1장 HTTP 개관

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

HTTP = HyperText Transfer Protocal

• HTTP 는 신뢰성 있는 전송 프로토콜
  • 전송 중간에 파괴 , 중복 , 왜곡 걱정이 없다

2. 웹 클라이언트와 서버

• 클라이언트가 특정 리소스를 필요할 것이다 그 리소스를 얻기 위해 어떻게 작용할까
  • 리소스(resource;;자원)

• 클라이언트는 리소스가 필요할때마다 server에게 HTTP Request를 보내고 server는 그에 맞는 HTTP Response를 반환하는 형태로 리소스를 보여준다
• 예를 들면 브라우저(크로,edge같은) 가 www.naver.com 서버에게 HTTP요청을 보내면 naver 서버는 응답을 보내고 화면을 띄우는 형태로 리소스를 얻는다.

3. 리소스 ( Resource)

• 웹 서버가 관리하는 것 == 리소스

리소스의 형태

1. 서버 파일 시스템의 정적 파일 (그림 파일, 텍스트, 이미지……etc)
2. 동적 파일 (요청 유저가 누구인지에 따라 다르게 나타내거나 아님 시간에 따라 다르게 나타내는 파일)

<aside> 💡 요약: 웹의 모든 종류의 콘텐츠도 리소스가 될 수 있다.

</aside>

3-1 미디어 타입 MIME

MIME ( Multipurpose Internet Mail Extensions)

• 인터넷에서는 수천가지 데이터 타입을 다루기 때문에 HTTP는 웹에서 전송된 객체 각각에 신중하게 MIME타입이라는 데이터 포멧 라벨을 붙인다
• server 가 MIME 타입을 응답에 같이 보내면 client 는 MIME 타입을 보고 다룰 수 있는 객체인지 확인한다.
• 예) HTML 문서 text/html 그리고 JPEG image/jpeg …etc
  • 수백가지의 잘알려진 MIME 타입과 그보다 더 많은 실험용 혹은 특정 용도의 MIME 타입이 존재한다.

3-2 URI ( Uniform Resource Identefier) 통합 자원 식별자

• 웹 서버의 리소스들은 각자 이름을 갖고 있기 때문에, 클라이언트들은 관심있는 리소스를 지목할 수 있다. → 이때 필요한게 URI
• 웹 서버의 리소스들은 고유한 주소나 이름을 가짐 → URI
• URI의 종류
  1. URL (Uniform Resource Locators) 통합 자원 지시자 (널리쓰임)
  2. URN (Uniform Resource Name) 통합 자원 이름
• URL은 정확한 주소 → 리소스가 정확히 어디에 있고 어떻게 접근한지 정확히 명시한 것이다.
  • ex) http://www.naver.com//index.html
    • http → scheme(스켐)이라고 불리며 리소스에 접근하기 위한 프로토콜 명시
    • www.naver.com 호스트명 서버의 주소
    • index.html → 서버에서의 리소스 주소
• URN은 어떤 특정 자원의 유일한 독립적인 이름을 뜻함.
  • 이름을 안다면 자원의 위치가 바뀐다 하더라도 찾을 수 없음
  • 널리 쓰이진 못함 인프라가 협소해서?

<aside> 💡 통상적으로 언급없이는 URI == URL로 봐도 무방하다 그만큼 URL을 널리 쓰이기 때문

</aside>

4. 트랜잭션

• 트랜잭션이란?
  1. 요청 명령
  2. 응답 결과
  로 구성 되어있다.
• 트랜잭션은 HTTP 메세지라는 정형화 된 데이터 덩어리를 이용해 이루어진다.

4.1 메서드 (client)

• http 메서드라고 불리는 여러가지 종류의 요청 명령을 지원한다.
• 요청 명령 메서드(즉 client → server) 는 무조건 1개의 메서드를 가진다

GET 서버에서 클라이언트로 지정한 리소스를 보내라

PUT	클라이언트에서 서버로 보낸 데이터를 지정한 이름의 리소스를 저장하라
DELETE	지정한 리소스를 서버에서 삭제해라
POST	클라이언트 데이터를 서버 게이트웨이 애플리케이션으로 보내라
HEAD	지정한 리소스에 대한 응답에서 HTTP 헤더 부분만 보내라

4.2 상태코드 (server)

200 좋다

302	다시 보내라. 다른 곳에서 리소스를 가져가라
404	없음 리소스를 찾을 수 없다

• 응답 결과에는 (응답 메세지)는 모두 상태코드와 함께 반환
• 3자리로 구성, HTTP는 각 숫자 상태코드에 텍스트와 함께 사유구절로 함께 보낸다.

4.3 웹페이지는 여러 객체로 이루어져 있다.

• 웹페이지는 여러 리소스를 필요하는 순간이 많다 그래서
• 여러번의 트랜잭션이 작용한다..

5. 메세지(HTTP 메세지의 구조는?)

• HTTP 메세지는 단순한 줄 단위 문자열이다.
• 이진 형식이 아닌 일반 텍스트이기 때문에 사람이 읽고 쓰기 쉽다.
• 메세지의 형태
  1. 시작줄
  2. 헤더
  3. 본문
• 시작줄 (무엇을 해야하는지 or 무엇이 일어 났는지)
  • 요청 메세지: 요청 메서드 리소스 주소 프로토콜 버전 등이 들어간다.
  • 응답 메세지: 상태코드 프로토콜 버전 그리고 사유구절 등이 있다.
• 헤더 (리소스 정보?로 이해함)
  • 하나의 이름 : 하나의 값으로 구성되어 있음
  • 요청 메세지에는 host정보나
  • 응답 메세지에는 리소스 정보 그리고 리소스 MIME 타입이 있음
• 본문 (알멩이)
  • 만약 GET 요청을 보냈다면
  • 응답 메세지에 GET 요청을 보낸 리소스를 본문에 넣는다.
  • 본문은 이진 파일도(이미지 동영상 음성) 올 수 있고 물론 텍스트(HTML,text)파일도 가능하다.
  • 본문은 요청 응답 1개만 있을 수 있고 2개 다 있을 수 도 있다.

6. TCP 커넥션

• 이제 메세지가 어떻게 생겼는지 보았다.
• TCP 커넥션은 어떻게 메세지를 보내는지 알 수 있다.

6.1 TCP/IP

• HTTP는 애플리케이션 계층 프로토콜이다.
  • 네트워크 통신의 핵심적인 세부 사항에 대해서 신경x
  • 대신 대중적이고 신뢰성있는 인터넷 전송 프로토콜(Transmission Control Protocol: 전송 제어 프로토콜) TCP를 사용한다.
• TCP는 다음을 제공한다
  • 오류없는 데이터 전송
  • 순서에 맞는 전달
  • 조각나지 않는 데이터 스트림
• TCP/IP는 TCP와 IP가 층을 이루는 패킷 교환 네트워크 프로토콜의 집합
  • 네트워크와 하드웨어의 특성을 숨기고 신뢰성있는 의사소통을 하게 한다.
• 일단 TCP 커넥션이 맺어지면 클라이언트와 서버 컴퓨터 간에 교환되는 메세지가 없어지거나, 손상되거나, 순서가 바뀌는 일은 없다.

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

• HTTP 클라이언트가 서버에 메세지를 전송할 수 있게 되기 전
• 인터넷 프로토콜(Internet Protocal: IP) 주소와 포트번호를 사용하여 클라이언트와 서버 사이에 TCP/IP 커넥션을 맺어야 한다.
  • 서버의 IP와 서버에서 실행중인 프로그램의 포트번호는 어떻게 알까?http://205.23.5.2:80/index.html
  • http://www.naver.com:80/index.html
  • →URL
  • IP주소는 DNS(Domain Name Service)로 IP주소를 도메인 명으로 도메인 명을 IP주소로 변환할 수 있다.
  • port번호는 생략되면 디폴트가 80이다.
• 결론 메세지가 보내지는 순서
  1. 웹브라우저는 서버의 URL에서 호스트명 추출
  2. 웹 브라우저는 서버의 호스트명을 IP 변환
  3. 웹 브라우저는 Port 추출
  4. 웹 브라우저는 서버와 TCP 커넥션을 맺음
  5. 웹 브라우저는 HTTP 요청을 보낸다.
  6. 서버는 HTTP 응답을 돌려준다.
  7. 커넥션이 닫히면 웹브라우저는 문서를 보여준다.

7. 웹의 구성요소

• 인터넷과 상호작용할 수 있는 웹 애플리케이션은 많다.

1. 프락시: 클라이언트와 서버 사이에 위치한 HTTP 중개자
2. 캐시: 많이 찾는 웹페이지를 클라이언트 가까이에 보관하는 HTTP 창고
3. 게이트 웨이: 다른 애플리케이션과 연결된 특별한 웹 서버
4. 터널: 단순히 HTTP 통신을 전달하기만 하는 특별한 프락시