[1장] 1.1 ~ 1.6

책을 읽고 공부한 내용을 기록한 글입니다.

 

HTTP 통신은 신뢰성있는 프로토콜이다. 이말은 곧 받은 정보가 결함이 있음을 배제한다는 말과 같다.

웹 클라이언트와 서버

클라이언트가 HTTP 요청을 서버로 보내면, 서버는 HTTP 응답을 클라이언트에게 보낸다. 그리고 이 중간엔 브라우저가 존재한다.

stateDiagram-v2
    client --> browser
    browser --> client
    browser --> server
    server --> browser

리소스

리소스는 웹 콘텐츠의 원천이고, 웹 서버가 이를 관리하고 제공한다. 정적파일일 수도, 동적 리소스 일 수도 있다. 정적 리소스가 문서파일, 이미지, 이미 촬영되어 저장된 영상파일 같은 것이라면 동적 리소스는 사용자에 따라, 요청 값에 따라, 시간에 따라 다른 콘텐츠를 만들어낸다. 웹 서버에 존재하는 모든 콘텐츠를 리소스라고 큰 범주에서 볼 수 있다.  또 웹 페이지는 하나의 객체가 아니라, 여러 트랜잭션을 통해 여러 객체로 구성된 리소스 모음이다.

리소스 중 HTTP는 MIME(Multipurpose Internet Mail Extensions) 타입이라는 데이터 포맷 라벨을 붙여 데이터를 주고 받는다. 원래는 이메일에 썼고 HTTP로 확장되었다. 

https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/MIME_types

MIME 타입 (IANA 미디어 타입) - HTTP | MDN

HTTP 통신 중 Content-type에 붙는 게 MIME 타입이다. 

POST /foo HTTP/1.1
Content-Length: 68137
Content-Type: multipart/form-data;

이때 왼쪽이 primary 타입(큰 범주), 오른쪽이 sub 타입이다. 예시로 가져온 코드로는 multipart이고 form-data를 POST방식으로 요청하고 있음을 알 수 있다.

URI, URL, URN

URI(uniform resource identifier)는 통합 자원 식별자로 서버 리소스이다. 정보 리소스를 고유하게 식별하고 위치를 지정할 수 있는 일종의 우편번호 같은 개념이다. 처음 접했을 때 URL과 계속 헷갈렸었다. 리소스에 대한 주소값이라고 이해하는 게 빠르다.

HTTP는 URI에 적힌대로 리소스 객체를 찾아온다.

URI는 큰 개념으로 URL(통합 자원 지시자)와 URN으로 나눠진다.

flowchart TD
    C{URI}
    C -->|유일한 식별 명| D[URN]
    C -->|프로토콜, 서버주소, 리소스| F[URL]

URN은 어디서나 지칭해서 리소스 위치를 파악해 사용가능한 식별자 같은건데 사실상 잘 안쓰이고, URL은 특정 서버의 한 리소스에 대한 구체적인 위치를 프로토콜(scheme)과 함께 지정해주는 아주 구체적인 식별자라고 볼 수 있다. 통상 URI = URL이라고 본다.

트랜잭션

HTTP는 HTTP 메시지라고 불리는 정형화된 데이터 덩어리를 주고받는 데(요청메시지 - 응답메시지), 이를 HTTP 트랜잭션이라고 한다.

요청할 때는 URI와 명령을, 응답에는 트랜잭션의 결과를 포함한다.

 

모든 HTTP 요청 메시지(클라이언트 -> 서버)는 한 개의 메서드를 가지며, 흔히 GET/POST/DELETE/PUT/HEAD 가 자주 쓰이고, RESTful 형식도 앞에 네 메서드로 정의된다.

모든 HTTP 응답 메시지(서버 -> 클라이언트)는 상태코드와 함께 반환된다. 흔히 볼 수 있는 403 forbidden, 404 not found 같은 메시지도 상태코드에 속한다.

1xx (정보): 요청을 받았으며 프로세스를 계속한다
2xx (성공): 요청을 성공적으로 받았으며 인식했고 수용하였다
3xx (리다이렉션): 요청 완료를 위해 추가 작업 조치가 필요하다
4xx (클라이언트 오류): 요청의 문법이 잘못되었거나 요청을 처리할 수 없다
5xx (서버 오류): 서버가 명백히 유효한 요청에 대해 충족을 실패했다

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

HTTP 상태 코드 - HTTP | MDN

처음 404가 클라이언트 오류라고 했을 때 의문이었지만 잘못된 곳에 액세스한 결과지 서버는 잘못이 없다는 걸 알고 이해가 됐다.

상태코드에 reason phrase를 붙여서 보내는데 이건 완전히 상태코드와 동일한 것으로 보고, 상태코드만을 이용해 처리한다. 

이 개념을 모르고 있어서 백엔드와 첫 협업때 이 메시지를 잡아서 뭘 하려고 했던 기억이 난다.

메시지

HTTP 메시지는 세 부분으로 나뉜다. 시작줄/ 헤더/ 본문으로 각각

1. 시작줄 - HTTP 버전도 포함된다. 
   어떤 요청인지(HTTP메서드 이름), 어떤 상태인지(상태코드) 가 담겨있다.
2. 헤더
   헤더는 여러줄로 이루어져있고 어떤 MIME타입의 콘텐츠인지 알려준다. 헤더의 끝을 알아보려면 빈줄이 있는 지 보면 된다.
3. 본문
   요청의 본문은 POST와 PUT이 사용하고 웹서버로 데이터를 실어보내며, 응답의 본문은 클라이언트의 요청에 대한 응답 데이터를 반환한다. 이 경우 이진파일로 인코딩된 이미지, 영상같은 것도 반환 가능하다. 

TCP 커넥션

네트워크 계층 얘기로 잠깐 내려와서, HTTP는 Application layer다. HTTP가 신뢰성 있는 통신을 한다는 건 TCP가 배경이기 때문이다.

TCP/IP 프로토콜은 UDP와 다르게 오류없는 데이터 전송, 순서가 꼬이지 않는 데이터조각들, 깨지지 않는 데이터 스트림(크기제한, 시간 제한 같은 경우) 과 같은 특징을 갖고있다.

 

HTTP는 포트번호 80, HTTPS(SSL위에 HTTP 띄운것)는 443을 사용한다.

IP 주소와 포트번호를 이용해 클라이언트-서버 간 TCP/IP 커넥션을 맺어 손쉽게 통신할 수 있다. URL에 있는 도메인 주소는 DNS서버를 통해 IP주소로 변환되어 나간다.

 

웹 브라우저는 어떻게 사용자에게 화면을 보여주는 지에 대한 순서는 다음과 같다.

1. 브라우저가 서버의 URL(도메인)에서 호스트 명을 추출한다(웹 주소)
2. 웹 브라우저가 서버의 호스트 명을 IP주소로 변환한다(DNS를 거쳐서)
3. 포트번호가 있다면 그걸 가져가고, 없으면 80을 기본으로 한다.
4. 브라우저가 웹 서버와의 TCP 커넥션을 IP주소와 포트번호를 이용해 맺는다.
5. 맺은 커넥션을 이용해 서버에 HTTP 요청을 보낸다.
6. 서버가 브라우저에 HTTP 응답을 돌려주고 커넥션이 닫힌다.
7. 브라우저는 받은 리소스를 기반으로 사용자에게 보여준다.

 

 

도움이 됐다면 댓글이나 공감 버튼 한 번씩 누르고 가주세요! 로그인 안해도 됩니다 ^_^