📗

HTTP Network Basic - 우에노 센

1. 웹과 네트워크의 기본

가. HTTP 버전

나. Request message 구성

가. request message and response message

1. 웹과 네트워크의 기본

가. HTTP 버전

•

HTTP/1.0: 1996년 정식 사양으로 공개, 초기사양, RFC1945 발행

•

HTTP/1.1: 1997년 공개, 개정판 RFC2616 버전 발행

→ 현재 가장 많이 사용되는 버전

•

HTTP/2.0: 책정은 되어 있지만 널리 사용되지 않고 있음

나. TCP/IP

•

TCP/IP: 인터넷과 관련된 프로토콜의 모음

→ 인터넷 상의 서로 다른 규격(하드웨어, OS 등)을 가진 컴퓨터 간의 통신을 지원하기 위해 일정한 규칙이 필요함

→ 이러한 규칙을 프로토콜이라함

•

TCP/IP 4계층: 어플리케이션 계층, 트랜스포트 계층, 네트워크 계층, 링크 계층

→ 계층화의 장점 1) 에러 발생 시, 에러 발생 지점을 특정할 수 있음 2) 설계 시, 계층 간 규칙을 지킨다는 전제 하에 내부는 자유롭게 만들 수 있음

→ 어플리케이션 계층: 어플리케이션 통신 ex) HTTP

→ 트랜스포트 계층: 데이터 흐름 통제 ex) TCP/UDP

→ 네트워크 계층: 목적지 노드까지의 여러 선택지 중 하나의 길 결정 ex) IP

→ 링크 계층: 하드웨어 ex) NIC

다. IP/TCP/DNS

•

IP: 도착지 정보(MAC 주소, IP 주소)를 기반으로 ARP 활용하여 중간지점을 들려서 목적지에 도착 

그 누구도 인터넷 전체를 파악하고 있지 않다

→ IP 주소: 도착지 노드 주소, 변경 가능

→ MAC 주소: 네트워크 카드(NIC)에 할당된 주소, 고유함

•

TCP: 정보의 단위를 잘게 쪼개어 데이터의 흐름을 원활하게 하고, 3-handshaking으로 신뢰성 있는 데이터 통신을 지원함

•

DNS: 텍스트 기반의 호스트 주소를 컴퓨터가 이해할 수 있는 IP주소로 변경

마. URI vs URL

•

URI: 표준형, URL을 포함하는 포괄적인 개념

•

URL: URI 보다 과거에 사용되던 표현

→ 클라이언트의 GET 요청에 따라 특정 자원을 할당받을 때 사용되었음

2. HTTP, 간단한 프로토콜

가. HTTP 규칙

•

HTTP 통신은 클라이언트와 서버를 구분함

→ 클라이언트는 서버에 요청(request)을 보내고 서버는 이에 대해 응답(response)을 보냄

•

HTTP 통신은 반드시 클라이언트의 request로부터 시작됨

나. Request message 구성

→ 빨간색: 메소드, URI, 프로토콜 버전

→ 파란색: 옵션 리퀘스트 헤더 필드

→ 초록색: 엔터티

GET /index.html HTTP/1.1
Host: www.hackr.jp
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 16

name=ueno&age=37
Plain Text
복사

•

Response message 구성

→ 빨간색: 프로토콜 버전, 상태코드, 상태코드 설명

→ 파란색: 옵션 리스폰스 헤더 필드

→ 초록색: 바디

HTTP/1.1 200 OK
Date: Tue, 10 Jul 2012 06:50:15 GMT
Content ~~~

<html>
...
Plain Text
복사

다. Stateless

•

Request나 Response의 내용은 일회성이므로 해당 메세지가 HTTP에 저장되지 않음

→ 많은 데이터를 빠르게 처리하기 처리하기 위함

→ 이를 보안하기 위해 쿠키, 세션, 토큰 등의 기술 도입

라. Request URI

•

Request 시, URI를 포함하여 웹 상의 특정 자원을 지정하여 요청할 수 있음

마. HTTP 메소드

•

GET: 리소스 취득, Request URI로 특정된 리소스를 요청

•

POST: 엔티티 바디 전송, 일반적으로 request 메세지에 엔티티 포함하여 전송 시 사용됨

•

PUT: 파일 전송, Request에 포함된 엔티티를 Request URI로 지정한 곳에 저장함

→ HTTP/1.1에 자체 인증 기능이 없기 때문에 일반적인 웹 사이트에는 사용되지 않음

→ 웹 어플리케이션의 인증과 함께 사용되거나 REST에 사용됨

•

DELETE: 파일 삭제, Request URI로 지정된 자원의 삭제를 요청함

→ 상세 설명은 PUT과 동일

•

HEAD: 메시지 헤더 취득, GET과 같은 기능을 수행하지만 response에 바디는 없고 header만 돌려받는다

→ URI 유효성 체크 및 리소스 갱신 시간 확인 목적으로 사용됨

•

OPTIONS: HTTP 메소드 중 지원하는 것 확인

•

TRACE: loop-back 발생, 

→ 보안상의 이유로 잘 사용되지 않음

•

CONNECT: 프록시에 터널링 요구

바. (TCP 상) 지속연결

•

비지속연결: HTTP 초기 버전, 매번 Request Response 반복할 때마다 TCP의 3-handshaking 시도

•

지속연결: Client나 Server에서 TCP 연결해제 전까지 Request, Response 교차 반복 

→ HTTP/1.1부터 정식사양으로 채택

•

파이프라인화: Request와 Response 각각에 대해 기다리지 않고 연속적으로 여러 request나 response 전달

→ request 3개를 동시에 먼저 보내고, response 3개가 동시에 오는 방식

사. 쿠키

•

HTTP의 Stateless를 보완하기 위해 도입

•

서버에서 특정 Client의 접속 기록을 유지하기 위해 사용됨

•

서버에서 최초 response 전송 시, response의 헤더 중 Set-Cookie 필드에 cookie를 포함해서 보냄

•

위의 response를 받은 client는 다음 request 때부터 해당 cookie를 포함하여 보냄

•

request에 포함된 cookie와 서버의 cookie를 비교하여 연결상태 확인

3. HTTP 메세지

가. request message and response message

•

최초의 개행 문자(CR+LF)로 메시지 헤더와 메시지 바디로 구분

•

Request Header

→ 리퀘스트 라인: 메소드, request URI, HTTP version

•

Response Header

→ 상태 라인: 상태 코드와 설명, HTTP version

나. 인코딩으로 전송 효율 높이기

•

HTTP로 데이터 전송 시 인코딩으로 전송 효율 높일 수 있음

•

메시지 바디: 8비트로 구성되어 통신

•

엔티티 바디: Request와 Response의 payload로 전송되는 정보

→ 엔티티 헤더 필드와 엔티티 바디로 구성

•

HTTP 메세지 바디의 역할: 엔티티 바디 운반

→ 인코딩 적용 시 엔티티 바디 내용이 변화됨

•

콘텐츠 코딩: 엔터티에 적용되는 인코딩

•

청크 전송 코딩(Chunked Transfer Coding): 사이즈가 큰 데이터를 전송할 경우 엔티티 바디를 분할해서 전송 

다. 멀티파트

•

여러 개의 엔티티를 하나의 메시지 바디 내부에 포함시킬 수 있음

•

멀티파트 사용 시 헤더 필드에 Content-type 추가

라. 기타

•

레인지 리퀘스트: 전체가 아니라 일부에 대한 범위를 지정해서 리퀘스트

•

네고시에이션: 같은 리소스에 request하지만 조건에 따라 적합한 response를 받음

4. HTTP 상태 코드

상태 코드가 현재 상황과 불일치할 수도 있다

가. 2xx 성공(Success)

•

Request 정상 처리

•

200 OK: 일반적인 request 정상 처리

•

204 No Content: 정상 처리 되었지만, Client에서 정보를 보내고 Server로부터 정보를 받지 않는 경우

•

206 Partial Content: 정상 처리 되었지만, Server가 부분적인 GET Request를 받은 경우

나. 3xx (Redirection)

•

Request 완료하기 위해 클라이언트에서 추가 동작 필요

•

301 Moved Permanently: 해당 URI에 대한 재확인 통보 

→ Request URI에 대한 수정 필요

→ 주로 URI 마지막에 슬래시가 빠져서 받는 상태 코드

http://example.com/sample
Plain Text
복사

•

302 Found: 해당 URI에 대한 일시적인 변경이 있음을 통보

→ Request URI에 대한 수정 필요

→ 단, METHOD의 변경을 금지함

ex) HTTP 표준, POST 요청을 GET 요청으로 redirect 금지. 하지만 업계에서는 이를 무시하고 POST 요청을 GET 요청으로 redirect하는 것이 관례화

→ HTTP/1.1 이후 302의 역할을 303과 307로 분할함

•

303 See Other: Request URI에 대한 리소스가 다른 URI에 할당되어 있으며, 다른 URI에 대해 GET으로 얻을 것을 명시

•

304 Not Modified: 조건부 리퀘스트에 대해 해당 조건이 일치하지 않음을 통보

•

307 Temporary Redirect: 최초 Request URI에 대해 변경된 URI로 재요청 필요

→ 최초의 요청의 method와 엔티티 바디를 그대로 이용해야 함

→ 최초의 요청이 POST 방식으로 회원가입에 필요한 정보를 담은 바디를 포함했다면, 재요청의 경우도 POST 방식이어야 하고 최초 회원가입 정보도 포함해야 함

다. 4xx Client Error

•

서버에서 Request 이해 불가

•

400 Bad Request: Request 구문이 잘못되어 있음을 통보

•

401 Unauthorized: 전달 받은 Request에 HTTP 인증 정보가 필요함을 통보

•

403 Forbidden: Request URI에 대한 접근 거부

→ 접근 거부 이유를 엔티티 바디에 기재하여 client에 통보함

→ 접근 거부 이유는 IP 주소의 접근제어, 파일 시스템에서 허가 받지 않은 유저 차단 등

•

404 Not Found: Request URI에 해당하는 자원이 서버에 없음

→ 서버에서 해당 Request에 대해 거부하고 싶을 때도 사용됨