굳건하게

안녕하세요, 여행벌입니다.

오늘은 HTTP 프로토콜 메소드에 이어서 HTTP 프로토콜의 정보에 해당하는 메시지에 대해서 알아보겠습니다.

[ HTTP 메시지 ]

HTTP 프로토콜에서 교환하는 정보를 HTTP메시지라고 부릅니다. 리퀘스트 측 HTTP메시지를 리퀘스트 메시지, 리스폰스 측 HTTP메시지를 리스폰스 메시지라고 부르고 다음과 같은 형태를 유지한다.

시작라인 / 메시지헤더 / CRLF(개행) / 메시지바디 순으로 이루어져있으며 메시지바디는 없을 수도 있습니다. 저번 포스팅에서 다뤘던 GET 메소드는 대부분 메시지 바디가 없습니다.

• 시작 라인 : 시작라인은 리퀘스트에서는 리퀘스트라인, 리스폰스에서는 상태라인 이라고 불립니다.
  • 리퀘스트라인 : 리퀘스트에 사용하는 메소드 / 리퀘스트 URI / HTTP 버전이 포함.
  • 상태라인 : 리스폰스 결과를 나타내는 상태코드와 설명 / HTTP 버전이 포함.
• 헤더 필드 : HTTP 전송에 필요한 모든 부가정보가 담겨있는 곳으로, 리퀘스트와 리스폰스의 여러 조건과 속성 등을 나타내는 각종 헤더 필드가 포함됩니다.
• 바디 필드 : 실제 전송할 데이터를 담고 있는 필드로 HTML 문서, 이미지, 영상, JSON 등 byte로 표현할 수 있는 모든 데이터가 들어갈 수 있다.

[ HTTP 인코딩 ]

 HTTP로 데이터를 전송할 경우 그대로 전송할 수도 있지만, 인코딩을 실시함으로써 전송 효율을 높일 수 있습니다. 전송할 때 인코딩을 하면 CPU 등의 리소스는 많이 사용하지만 더 효율적으로 데이터를 전송할 수 있습니다.

• 메시지 : HTTP 통신의 기본 단위로 옥텟시퀀스(Octet sequence)로 구성되고 통신을 통해서 전송.
• 엔티티 : 리퀘스트랑 리스폰스의 페이로드(Payload, 부가물)로 전송되는 정보로 엔티티 헤더 필드와 엔티티 바디로 구성.

 HTTP 메시지 바디는 리퀘스트랑 리스폰스에 관한 엔티디 바디를 운반해줍니다. 인코딩을 한다는 것은 엔티티 정보를 인코딩을 해서 메시지 바디에 실어서 보낸다는 뜻입니다.

참고!

콘텐츠 코딩(Content Codings)

엔티티에 적용하는 인코딩을 가리키는 용어로 엔티티 정보를 유지한 채로 압축을 해줍니다. 콘텐츠 코딩된 엔티티는 수신한 클라이언트 측에서 디코딩을 해서 이용합니다.

[ 청크 전송 코딩(Chunked transfer Coding) ]

 HTTP 통신에서는 리퀘스트했었던 리소스 전부에서 엔티티 바디의 전송이 완료되지 않으면 브라우저에 표시되지 않습니다. 그래서 사이즈가 큰 데이터를 전송하는 경우에는 데이터를 분할해서 조금씩 브라우저에 표시하는 청크 전송 코딩을 이용해야합니다.

청크 전송 코딩은 엔티티 바디를 청크 단위로 분해해서 전송합니다.

[ 여러 데이터를 보내는 멀티파트 ]

 메일의 경우에는 메일의 본문이나 복수의 첨부 파일을 붙여서 함께 보낼 수 있습니다. MIME( Multipurpose Internet Mail Extensions, 다목적 인터넷 메일 확장 사양 ) 은 이미지, 텍스트, 영상 등 다양한 데이터의 바이너리 데이터를 아스키 문자열에 인코딩하는 방법과 데이터 종류는 나타내는 방법등을 규정하고 있습니다. 이 MIME 의 확장 사양에 있는 Multipart 라고 하는 여러 다른 종류의 데이터를 수용하는 방법을 HTTP 에서도 사용해 하나의 메시지 바디 내부에 엔티티를 여러 개 포함해서 보낼 수 있습니다.

multipart/form-data : Web 폼으로부터 파일 업로드에 사용됩니다.

multipart/byteranges : 상태코드 206 리스폰스 메시지가 복수 범위의 내용을 포함하는 때에 사용됩니다.

[ 레인지 리퀘스트(Range Request) ]

 HTTP 통신에서 커넥션이 끊어지게 되면 엔티티 정보를 처음부터 다시 전달받아야합니다. 따라서, 문제가 생겼을 때 이전에 전달받은 범위 뒤에서부터 전달을 다시 받는 레인지 리퀘스트가 등장했습니다. 이름 그대로 엔티티의 범위를 지정해서 해당 범위 만을 리퀘스트 하는 방법입니다.

[ 콘텐츠 네고시에이션(Content Negotiation) ]

 같은 콘텐츠(내용)이지만 여러 개의 페이지를 지닌 웹 페이지가 있습니다. ( 구글 영어판, 한국어판 ) 이러한 웹 페이지에서 같은 URI에 액세스할 때에 적절한 웹 페이지를 표시해주는 구조를 콘텐츠 네고시에이션이라 합니다.

콘텐츠 네고시에이션은 제공하는 리소스를 언어와 문자 세트, 인코딩 방식 등을 기준으로 적합한 리소스를 판단합니다.

Accept / Accept-Cahrset / Accept-Encoding / Accept-Language / Content-Language

참고

- 김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식

- 그림으로 배우는 HTTP&Network Basic

안녕하세요, 여행벌입니다.

오늘은 HTTP 에서 지원해주는 다양한 메소드에 대해서 정리해보겠습니다.

[ HTTP 메소드 ]

HTTP 는 다양한 메소드를 지원해줍니다.

• GET : 리소스 조회
• POST : 요청 데이터 처리
• PUT : 리소스를 대체, 해당 리소스가 없으면 생성
• PATCH : 리소스 부분 변경
• DELETE : 리소스 삭제
• HEAD : GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
• OPTIONS : 대상 리소스에 대한 통신 기능 옵션을 설명
• CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
• TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

[ GET 메소드 ]

GET 메소드는 리퀘스트 URI로 식별된 리소스를 가져올 수 있도록 요구하는 메소드입니다. 가져올 리소스 내용은 지정된 리소스를 서버가 해석한 결과입니다.

• 리소스 조회
• 서버에 전달하고 싶은 데이터는 query를 통해서 전달
• 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많으므로 사용 X
• ( 최근 스펙에서는 바디에 데이터를 넣는 것을 허용했지만, 실무에서는 사용 X )

[ POST 메소드 ]

POST 메소드는 엔티티를 전송하고 엔티티 처리를 요구하는 메소드입니다. POST 메소드는 GET메소드와 함께 가장 많이 사용되는 메소드로 GET 메소드는 아니지만 어떤 메소드를 사용해야될 지 모르겠으면 POST 메소드를 사용하는 것도 하나의 방법입니다.

• 요청 데이터 처리
• 메시지 바디를 통해 서버로 요청 데이터 전달
• 서버는 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행
• 대상 리소스가 리소스의 고유한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청 (정식스펙)

[ PUT 메소드 ]

PUT 메소드는 리소스가 있다면 완전히 대체하고, 리소스가 없다면 새롭게 생성해주는 메소드로 파일을 전송하기 위해서 사용됩니다. 리퀘스트 중에 포함된 엔티티를 리퀘스트 URI로 지정된 곳에 보존하도록 요구합니다. 우리가 알고있는 덮어쓰기랑 동작 방식이 같습니다.

• 리소스가 있으면 대체 없으면 생성 ( 완전히 대체 )
• PUT은 클라이언트가 리소스 위치를 알고 URI 를 지정한다.

[ PATCH 메소드 ]

PATCH 메소드는 리소스의 일부분만 교체하는 메소드입니다.

• 리소스 부분 변경

[ DELETE 메소드 ]

DELETE 메소드는 파일을 삭제하기 위해 사용합니다. PUT 메소드와는 반대로 동작하며 리쉐크트 URI로 지정된 리소스의 삭제를 요구합니다.

• 리소스 제거

[ HEAD 메소드 ]

HEAD 메소드는 GET과 같은 기능이지만 메시지 바디는 돌려주지 않습니다.

• 리소스 조회

[ OPTIONS 메소드 ]

OPTIONS 메소드는 리퀘스트 URI로 지정한 리소스가 제공하고 있는 메소드를 조사하기 위해 사용합니다.

• 사용 가능한 메소드 조사

[ TRACE 메소드 ]

TRACE 메소드는 Web 서버에 접속해서 자신에게 통신을 되돌려 받는 루프백을 발생시킵니다. 리퀘스트를 보낼 때 "Max-Forwards" 라는 헤더 필드에 수치를 포함시켜 서버를 통과할 때마다 그 수치를 줄여갑니다. 클라이언트는 TRACE 메소드를 사용함으로써, 리퀘스트를 보낸 곳에 어떤 리퀘스트가 가공되어 있는지 등을 조사할 수 있습니다.

• 경로 추적

[ CONNECT 메소드 ]

CONNECT 메소드는 프록시에 터널 접속 확립을 요함으로써, TCP 통신을 터널링 시키기 위해서 사용됩니다.

• 프록시에의 터널링 요구

[ HTTP 메소드 속성 ]

- 안전 (Safe)

: 호출해도 리소스를 변경하지 않는 메소드를 안전하다고 한다. 계속 호출해서 장애가 나는 경우는 고려하지않고, 해당 리소스가 변하는지만 고려한다.

- 멱등 (Idempotent)

: 몇 번 호출하든 결과가 똑같은 메소드를 멱등하다고 한다. 서버가 정상 응답을 하지 못했을 때, 멱등한 메소드는 자동적으로 다시 호출하도록 복구 메커니즘을 만드는데 사용한다. 또, POST는 멱등이 아니다. 결제하는 경우를 생각해보면 POST는 2번 호출하면 중복 결제가 된다.

- 캐시가능 (Cacheable)

: 응답 결과 리소스를 캐시해서 사용해도 되는 메소드를 캐시가능하다고 한다.

참고

- 김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식

- 그림으로 배우는 HTTP&Network Basic

안녕하세요, 여행벌입니다.

오늘은 가장 중요한 프로토콜인 HTTP 에 대해서 정리해보겠습니다.

 [ 웹 ( Web ) ]

 WWW( World Wide Web ) 은 인터넷에 연결된 사용자들이 서로 정보를 공유할 수 있는 공간을 의미합니다.

 인터넷이랑 웹은 다른 개념으로 인터넷상의 하나의 서비스가 웹입니다. 이러한 WWW를 구성하는 기술로, 문서 기술 언어로는 HTML, 문서 전송 프로토콜로는 HTTP, 문서의 주소 지정 방법으로는 URL 을 사용 중입니다.

프로토콜

컴퓨터와 네트워크 기기가 상호간에 통신하기 위해서는 서로 같은 방법으로 통신을 해야한다. 어떻게 상대를 찾고, 어떻게 상대에게 이야기를 시작하고, 어떠한 언어로 이야기를 하며, 어떻게 이야기를 종료할까와 같은 규칙이 프로토콜이다.

[ HTTP 프로토콜 역사 ]

 WWW 에서 문서 전송 프로토콜로 처음 등장했다. HyperText MarkUp Language 인 HTML을 전송하는 프로토콜로 시작했지만, 현재는 HTTP 메시지에 모든 것을 전송하고 있고 심지어 서버간에 데이터를 주고 받을 때도 대부분 HTTP를 사용한다.

• HTTP/0.9 1991년 GET 메서드만 지원, HTTP 헤더X
• HTTP/1.0 1996년 메서드, 헤더 추가
• HTTP/1.1 1997년 현재에도 가장 많이 사용되고 있는 버전, TCP 프로토콜 기반
  • RFC2068(1997) -> RFC2616(1999) ->RFC7230~7235(2014)
  • 2014년도에 개정된 버전이 현재 사용중인 버전이다.
• HTTP/2 2015년 TCP 프로토콜 기반, 성능 개선
• HTTP/3 ~ING TCP 대신에 UDP를 사용해서 성능 개선에 초점

[ 클라이언트 서버 구조 ]

 HTTP는 기본적으로 클라이언트 - 서버 구조로 작동해서 역할이 명확히 구분되어있다. 리소스를 요청하는 쪽이 클라이언트, 리소스를 제공하는 쪽이 서버가 된다. 역할이 명확히 구분되어있으므로 서로 상대가 무슨 일을 하는지 신경 쓸 필요가 없다. 리소스 요청을 리퀘스트, 리소스 반환을 리스폰스 라고 한다.

참고 : 리퀘스트 없는 리스폰스는 없다!

[ 무상태프로토콜 ( stateless ) ]

 HTTP 프로토콜은 상태를 유지하지 않는 스테이트리스 프로토콜입니다. HTTP 프로토콜 독자적으로, 리퀘스트와 리스폰스를 교환하는 동안에 상태를 관리하지 않습니다. 결국, HTTP 프로토콜 레벨에서는 이전에 보냈던 리퀘스트나 이미 되돌려준 리스폰스에 대해서는 전혀 기억하지 않습니다.

• 장점 : 서버 확장성이 높음(스케일 아웃) --> 서버를 확장해야될 때 기존의 상태를 기억할 필요가 없다!
• 단점 : 클라이언트가 추가 데이터를 계속 전송해줘야됨.

참고 !

웹이 발전함에 따라 스테이리스 특성만으로는 처리하기 어려운 상황이 생겨서 이를 해결하는 쿠키, 세션이 등장함!

[ 비연결프로토콜 ( connectionless ) ]

 HTTP 프로토콜은 리퀘스트가 발생하면 연결을 하고 리스폰스를 보낸 후 연결을 끊습니다.

 따라서, 서버 자원을 매우 효율적으로 사용할 수 있습니다. 리퀘스트를 요청한 모든 클라이언트와 계속 연결 상태를 유지하게 된다면 추가 리퀘스트를 보내지 않는 클라이언트들이 서버 자원을 낭비하게됩니다.

ex) 쇼핑몰 사이트에 들어가서 옷을 검색!(리퀘스트) --> 검색결과(리스폰스) --> 결과로 반환된 옷을 구경하면되지 연결상태 필요 X

[ 지속연결 ( Persistent Connections ) ]

HTTP 프로토콜은 비연결프로토콜이므로 트랜스포트, 네트워크 계층에서 TCP, IP 프로토콜을 통해 매번 연결을 새로 맺어야하는 문제가 있습니다. 또, 요즘은 하나의 웹 페이지에서도 HTML, CSS, JS 등 많은 리소스가 다운로드되어야하므로 매번 새로운 연결을 하는 것은 비효율적입니다.

이 문제를 해결하기 위해 HTTP/1.1 에서는 어느 한 쪽이 명시적으로 연결을 종료하지 않는 이상 TCP 연결을 계속 유지하는 지속연결 기능을 제공해줍니다.

이상으로, HTTP 기본 내용 정리를 마치겠습니다.

안녕하세요, 여행벌입니다.

오늘은 저번 IP(인터넷프로토콜)에 이어서 TCP / UDP 프로토콜에 대해서 정리해보겠습니다.

TCP / UDP 프로토콜은 인터넷 계층의 트랜스포트 계층에서 사용되는 프로토콜로 서로 다른 장/단점을 지니고 있습니다.

[ TCP 프로토콜 (전송 제어 프로토콜) ]

TCP 프로콜은 Transmission Control Protocol 의 약자로 전송 제어 프로토콜입니다. IP 프로토콜의 여러 문제점들을 해결해주는 프로토콜로 대용량의 데이터를 보내기 쉽게 작게 분해하여 상대에게 보내고, 제대로 도착했는지 확인하는 프로토콜입니다. 출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보 등의 내용을 포함하고 있습니다.

• 연결지향 - 3 way handshake
• 데이터 전달 보증
• 순서 보장
• 신뢰할 수 있는 프로토콜

[ TCP 3 way handshake ]

TCP 프로토콜은 데이터를 보낼 상대가 받을 수 있는 상태인지 확인하기 위해 3-Way-Handshake 기법을 사용합니다. 물리적으로 연결되는 것이 아니라 논리적으로 연결하는 과정으로 IP 프로토콜의 비연결성 문제를 해결합니다.

3-Way-Handshake는 SYN ACK 라는 TCP 플래그를 이용해 패킷이 보내졌는지 여부를 확인하는 방법입니다. 

( SYN : 접속요청 / ACK : 요청수락 )

과정은 다음과 같습니다.

​ 1) 클라이언트는 서버에 접속을 요청하는 SYN 패킷을 보냅니다.

​ 2) 서버는 클라이언트의 요청인 SYN 패킷을 받고, 클라이언트에게 요청을 수락한다는 ACK 패킷과 SYN 패킷을 보냅니다.

​ 3) 클라이언트는 서버의 수락 응답인 ACK 패킷과 서버가 보낸 SYN 패킷을 받고 SYN 패킷을 잘 받았다고 ACK 패킷을 서버로 보냅니다.

클라이언트가 SYN 플래그로 상대에게 접속함과 동시에 패킷을 보내고, 서버는 SYN/ACK 플래그로 클라이언트에 접속함과 동시에 패킷을 받은 사실을 전합니다. 마지막으로 클라이언트가 ACK 플래그를 보내 패킷 교환이 완료되었음을 전합니다.

참고!

물리적으로 연결된거는 아님! 가상 연결!

[ TCP 4 way handshake ]

TCP 프로토콜에서는 연결을 끊기 위해서 4-Way-Handshake 기법을 사용합니다.

​ 1) 클라이언트가 TCP Header의 flags 필드의 FIN 을 셋팅하여 연결을 종료하겠다는 FIN 플래그를 전송합니다.

​ 2) FIN 플래그를 받은 서버는 ACK 패킷을 전송하고 서버를 CLOSE_WAIT 상태로 TimeOut을 겁니다.

​ 3) 서버는 데이터를 모두 보내고 통신이 끝났으면 연결이 종료되었다고 클라이언트에게 FIN 플래그를 전송합니다.

​ 4) 클라이언트는 FIN 플래그를 확인했다는 ACK 패킷을 서버로 보내고 서버는 ACK 패킷을 받고 연결을 close 합니다.

TCP Header에는 Code Bit(flag bit) 라는 6Bit 짜리 Bit 가 존재하고, Urg-Ack-Psh-Rst-Syn-Fin 순서로 해당 패킷이 어떤 내용을 담고 있는 패킷인지를 나타내는 비트가 존재합니다.

SYN : Synchronize Sequence Number

ACK : ACKnowledgement

[ PORT ]

같은 IP 내에서 프로세스를 구분하는 주소입니다. 같은 IP 주소에 있는 여러 개의 애플리케이션을 구분하기 위해 등장한 개념으로 TCP 프로토콜은 PORT 정보를 가지고 있습니다.

• 0 ~ 65535 할당 가능
• 0 ~ 1023 : 잘 알려진 포트 --> 사용하지 않는 것이 좋음!
• HTTP - 80포트
• HTTPS - 443포트

IP를 아파트, PORT를 몇동 몇호 라고 생각하자!

[ UDP 프로토콜 (사용자 데이터그램 프로토콜) ]

UDP 프로토콜은 IP프로토콜과 크게 다르지는 않습니다. PORT 정보랑 체크섬 정보만 추가되서 연결을 보장하지 않고, 데이터 전달 보증, 순서 보장을 모두 지원해주지 않습니다. 하지만 그만큼 TCP 프로토콜에 비해 빠르기 때문에 HTTP3에서는 UDP 프로토콜을 기반으로 동작합니다.

참고!

기존에는 대부분 TCP 프로토콜 기반이였으나 HTTP3에서는 UDP 프로토콜 기반!

[ DNS ( 도메인 네임 시스템 ) ]

IP 주소는 외우기도 어렵고, 변경될 수도 있으므로 IP 주소로 통신하는데 어려움이 있었습니다. 그래서 호스트의 도메인 이름을 호스트의 네트워크 주소로 바꾸거나 그 반대의 변환을 수행할 수 있도록 해주는 시스템인 도메인 네임 시스템이 등장했습니다.

[ URI (Uniform Resource Identifier) ]

네트워크 상에서 자원이 어디있는지를 알려주는 규약을 URI 라고 합니다. 우리가 흔히 자주 사용하는 URL 은 URI에 포함된 개념이고 URN 과 URL 이 합쳐져서 URI 가 되는데 URN 은 사용하지 않으므로 URI를 URL로 이해해도 괜찮습니다.

• Uniform : 리소스를 식별하는 통일된 방식
• Resource : URI로 식별할 수 있는 모든 것
• Identifier : 다른 항목과 구분하는데 필요한 정보

URI 는 로케이터(locator), 이름(name) 또는 둘 다 이용해서 자원을 식별.

URL 은 로케이터(locator) 으로 자원을 식별

URN 은 이름(name) 으로 자원을 식별

이상으로 TCP / UDP 프로토콜 정리를 마치겠습니다.

참고

- 김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식

- 그림으로 배우는 HTTP&Network Basic