.jpg)
IP (Internet Protocol)
클라이언트와 서버가 통신하기 위해 인터넷 프로토콜 주소를 컴퓨터에 부여하여 이를 이용해 통신이 이루어진다. IP는 지정한 IP 주소(IP Address)에 패킷(Packet)이라는 통신 단위로 데이터 전달을 하게 된다.
패킷은 pack과 bucket이 합쳐진 단어로 소포로 비유할 수 있다. IP 패킷은 우체국 송장처럼 전송 데이터를 무사히 전송하기 위해 출발지 IP, 목적지 IP와 같은 정보가 포함되어 있다. 패킷 단위로 전송을 하면 노드들은 목적지 IP에 도달하기 위해 서로 데이터를 전달한다. 이를 통해 복잡한 인터넷 망 사이에서도 정확한 목적지로 패킷을 전송할 수 있다. 서버에서 무사히 데이터를 전송받는다면 서버도 이에 대한 응답을 IP 패킷을 이용해 클라이언트에 전달한다.
그러나 한계점도 존재한다. 먼저 패킷을 받을 대상이 없거나 서비스 불능 상태여도 클라이언트는 서버의 상태를 파악할 방법이 없기 때문에 패킷을 그대로 전송하게 된다는 비연결성이다. 다음으로는 중간에 있는 서버가 데이터를 전달하던 중 장애가 생겨 패킷이 중간에 소실되더라도 클라이언트는 이를 파악할 방법이 없다는 비신뢰성이 있다. 또한 전달 데이터의 용량이 클 경우 이를 패킷 단위로 나눠 데이터를 전달하게 되는데 이때 패킷들은 중간에 서로 다른 노드를 통해 전달될 수 있고 클라이언트가 의도하지 않은 순서로 서버에 패킷이 도착할 수도 있다는 점도 있다.
TCP vs UDP
TCP
- 연결 지향: TCP 3 way handshake(가상 연결)
- 장치들 사이에 논리적인 접속을 성립하기 위하여 3 way handshake를 사용하는 연결지향형 프로토콜이다.
- 클라이언트는 서버에 접속을 요청하는 SYN(Syncronize) 패킷을 보낸다. 서버는 SYN요청을 받고 클라이언트에게 요청을 수락한다는 ACK(Acknowledgment)와 SYN가 설정된 패킷을 발송하고 클라이언트가 다시 ACK으로 응답하기를 기다린다. 클라이언트가 서버에게 ACK을 보내면 이 이후로부터 연결이 성립되며 데이터를 전송할 수 있다. 만약 서버가 꺼져있다면 클라이언트가 SYN을 보내고 서버에서 응답이 없기 떄문에 데이터를 보내지 않는다. 현재에는 최적화가 이루어져 3번 ACK을 보낼때 데이터를 함께 보내기도 한다.
- 데이터 전달 보증
- TCP는 데이터 전송이 성공적으로 이루어진다면 이에 대한 응답을 돌려주기 때문에 IP 패킷의 한계인 비연결성을 보완할 수 있다.
- 순서 보장
- 만약 패킷이 순서대로 도착하지 않는다면 TCP 세그먼트에 있는 정보를 토대로 다시 패킷 전송을 요청할 수 있다. 이를 통해 IP 패킷의 한계인 비신뢰성(순서를 보장하지 않음)을 보완할 수 있다.
- 신뢰할 수 있는 프로토콜
- TCP 세그먼트에는 IP 패킷의 출발지 IP와 목적지 IP 정보를 보완할 수 있는 출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보 등을 포함한다.
- 같은 계층에 속한 UDP에 비해 상대적으로 신뢰할 수 있는 프로토콜이다.
UDT
- IP 프로토콜에 PORT, 체크섬 필드 정보만 추가된 단순한 프로토콜이다.
- 비록 데이터 전달 보증도 되지 않고 순서 보장도 되지 않아 신뢰성은 낮지만 3 way handshake 방식을 사용하지 않기 때문에 TCP와 비교해 빠른 속도를 보장한다.
- 따라서 신뢰성보다는 연속성이 중요한 실시간 스트리밍 서비스 등에 주로 사용된다.
- HTTP3는 UDP를 사용하며 이미 여러 기능이 구현된 TCP보다는 하얀 도화지처럼 커스터마이징이 가능하다는 장점이 있다.
HTTP (HyperText Transfer Protocol)
- 웹 브라우저와 웹 서버의 소통을 위해 디자인되었다.
- 클라이언트 서버 구조
- 클라이언트의 요청을 보내고 응답을 대기하면 서버가 요청에 대한 결과를 만들어 응답하는 구조로 이루어져 있다.
- 무상태 프로토콜(Stateless)
- 서버가 클라이언트의 상태를 보존하지 않아(Stateless) 서버 확장성이 높다는 장점(응답 서버를 쉽게 바꿀 수 있어 무한한 서버가 증설이 가능)이 있으나 클라이언트가 추가 데이터를 전송해야 한다는 단점이 있다.
- 로그인이 필요 없는 단순한 서비스 소개 화면 같은 경우엔 무상태로 설계할 수 있지만 로그인이 필요한 서비스라면 유저의 상태를 유지해야 되기 때문에 브라우저 쿠키, 서버 세션, 토큰 등을 이용해 상태를 유지해야 한다는 한계가 있다.
- 비연결성(Connectionless)
- TCP/IP의 경우 기본적으로 연결을 유지하는데 요청이 존재하지 않더라도 이 연결을 유지하는 데에 서버의 자원이 계속해서 소모된다. 그러나 비연결성을 가지는 HTTP에서는 실제로 요청을 주고받을 때만 연결을 유지하고 응답을 주고 나면 TCP/IP 연결을 끊어 최소한의 자원으로 서보 유지를 가능하게 한다.
- 트래픽이 많지 않고, 빠른 응답을 제공할 수 있는 경우, 비연결성의 특징은 효율적으로 작동한다.
- 하지만 트래픽이 많고, 큰 규모의 서비스를 운영할 때에는 웹 브라우저로 사이트를 요청하면 HTML뿐만 아니라 자바스크립트, css, 추가 이미지 등 수많은 자원이 함께 다운로드되는데 해당 자원들을 각각 보낼 때마다 연결 끊고 다시 연결하고를 반복하는 것은 비효율적이기 때문에 지금은 HTTP 지속 연결(Persistent Connections)로 문제를 해결한다. HTTP 초기에는 각각의 자원을 다운로드하기 위해 연결과 종료를 반복해야 했으나 HTTP 지속 연결에서는 연결이 이루어지고 난 뒤 각각의 자원들을 요청하고 모든 자원에 대한 응답이 돌아온 후에 연결을 종료한다.
HTTP Message
HTTP messages 는 클라이언트와 서버 사이에서 데이터가 교환되는 방식이다. HTTP messages는 요청(Requests)과 응답(Responses)으로 이루어지며 구성 파일, API, 기타 인터페이스에서 HTTP messages를 자동으로 완성되어 개발자가 직접 작성할 필요가 거의 없다.
- start line : start line에는 요청이나 응답의 상태를 나타낸다. 항상 첫 번째 줄에 위치하며 응답에서는 status line이라고 부른다.
- HTTP headers : 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합이다.
- empty line : 헤더와 본문을 구분하는 빈 줄이다.
- body : 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함한다. 요청과 응답의 유형에 따라 선택적으로 사용한다.
이 중 start line과 HTTP headers를 묶어 요청이나 응답의 헤드(head)라고 하고, payload는 body라고 한다.
웹 캐시의 기본 원리 및 적용
캐시(데이터나 값을 미리 복사해 놓는 임시 장소)가 없을 경우 동일한 정보에 대해 네트워크를 통해 같은 데이터를 계속해서 다운받아야만 한다 용량이 클 수록 비용이 커지고 브라우저의 로딩 속도가 느려지는 단점이 있다.
캐시(cache)는 컴퓨터 과학에서 데이터나 값을 미리 복사해 놓는 임시 장소를 가리킨다. 캐시는 캐시의 접근 시간에 비해 원래 데이터를 접근하는 시간이 오래 걸리는 경우나 값을 다시 계산하는 시간을 절약하고 싶은 경우에 사용한다. 캐시에 데이터를 미리 복사해 놓으면 계산이나 접근 시간 없이 더 빠른 속도로 데이터에 접근할 수 있다. 브라우저에 캐시를 저장할 땐 헤더에 cache-control 속성을 통해 캐시가 유효한 시간을 지정할 수 있다. 이 경우 60초로 설정한다면 60초 동안은 해당 캐시가 유효하다는 의미가 된다.
이렇게 되면 다음에 일어나는 요청에서는 캐시를 우선 조회하게 된다. 캐시가 존재하고 유효기간이 지나지 않았다면 캐시에서 데이터를 가져오게 된다.
캐시 검증 헤더와 조건부 요청
캐시 유효시간이 지났지만 변경이 없기 때문에 해당 데이터를 써도 되는 상황에서 이를 검증하고 사용하는 방법으로는 검증 헤더 Last Modified를 이용해 캐시의 수정시간을 알아내는 것이 있다. Last Modified는 데이터가 마지막으로 수정된 시간 정보를 헤더에 포함한다. 이로 인해 응답 결과를 캐시에 저장할 때 데이터 최종 수정일도 저장된다. 서버의 해당 자료의 최종 수정일과 비교해서 데이터가 수정이 안되었을 경우 응답 메시지에 이를 담아서 알려준다. 이때 HTTP Body는 응답 데이터에 없으며 상태 코드는 304 Not Modified로 변경된 것이 없다는 뜻이다.
그러나 Last-Modified와 If-Modified-Since는 1초 미만 단위로는 캐시 조정이 불가능하며 데이터를 수정해서 날짜는 다르지만 같은 데이터를 수정해서 데이터 결과가 똑같은 경우를 구분할 수 없고 서버에서 별도의 캐시 로직을 관리하고 싶은 경우에는 단점을 가지고 있다.
이때 ETag와 If-None-Match 검증 헤더를 사용할 수 있다. 이는 캐시용 데이터에 임의의 고유한 버전 이름을 달아두고 데이터가 변경되면 이 이름을 바꾸어서 변경해 단순하게 Etag만 보내서 같으면 유지하고 다르면 다시 받는 방식이다. 이는 캐시 제어 로직을 서버에서 완전히 관리하는 방식이기도 하다.
