Today 요약
- 웹/HTTP/네트워크 책 읽기
1. What I Learned?
웹/HTTP/네트워크 책 읽기
TCP
앞서 IP는 택배만 전달할 뿐, 즉 데이터만 전달할 뿐 그 데이터 안에 내용이 담겨 있는지 아닌지를 판별하지 않는다고 했다. 이런 부분을 해결하기 위해 사용하는 프로토콜이 TCP다. TCP는 신뢰성을 중요하게 생각한다. 패킷으로 나눠져있는 데이터에 TCP 헤더의 정보를 캡슐화해서 보내며, 해당 헤더 정보에 패킷의 다양한 정보가 담겨있다. 이를 통해 순서대로 받을 수 있고 조합할 수 있게 해서 신뢰성 있는 데이터를 받을 수 있다.
TCP의 연결은 3way handshake의 과정을 거치며, 이를 통해 클라이언트와 서버가 연결을 수립한다. 클라이언트가 먼저 연결 요청을 보내고 그에 서버는 응답을 한다. 응답을 통해 서버가 연결을 할 준비가 되어 있다고 전해받은 클라이언트는 최종적으로 연결을 마무리할 요청을 보낸다.
그리고 더 이상 연결이 필요없을 때는 연결을 끊어줘야 하는데, 이때 4way handshake의 방법을 사용한다.
하지만 이런 TCP의 신뢰성있는 통신은 속도가 빠르지 않기 때문에 발생할 수 있는 문제점들이 존재한다. 통신과정에서의 문제점 중 하나는 데이터의 송신 속도가 차이가 발생할 수 있다는 점이다. 이런 흐름에 대한 제어를 해결할 수 있는 방법으로는 정지-대기 방식이 있다. 하나가 해결되면 다른 하나를 통신하는 방식이라 속도가 느리다는 단점이 있다. 이를 조금 더 해결한 방식이 슬라이딩 윈도 방식이다. 한 번에 보내는 데이터의 크기를 정해서 해당 크기의 데이터 만큼 보내고 그 데이터만큼의 크기가 들어왔다면, 다시 통신을 진행한다. 정지-대기 방식에 비해 빠르다.
하지만 데이터 전송 속도의 차이 말고도 네트워크 자체의 문제로 인한 문제점도 있다. 이 경우에는 혼잡을 제어해야 한다.
혼잡 제어 방식에는 합 증가/곱 감소와 느린 시작이라는 두 가지 방법이 있다.
합 증가/곱 감소 방식은 데이터를 하나씩 증가시켜가다가 네트워크의 장애나 다른 이유로 받는 쪽에서 제대로 수신을 못하고 있다면 1/2 만큼 감소시켜서 데이터를 보내고 다시 통신하고 반복하는 방식을 사용한다.
느린 시작 방식은 데이터를 1,2,4,8식으로 두 배씩 증가시켜서 보내다가 혼잡이 발생하면 다시 윈도 크기를 1로 초기화하는 방식을 말한다. 처음 시작이 느리기 때문에 느린시작 방식이라고 이름 지어졌지만, 혼잡이 자주 발생하지않으면 합 증가/곱 감소 방식보다 훨씬 빠르다.
하지만 이런 TCP의 방식도 결국에는 신뢰성을 보장으로 통신하기 때문에 속도가 느린 고질적인 문제를 해결하기는 어려웠고, 이에 맞춰 UDP라는 비신뢰성 프로토콜이 개발되었고, 신뢰성이 필요없는 경우 영상 스트리밍의 경우 UDP를 이용해서 통신하기도 한다.
HTTP
HTTP는 대표적인 특징 2가지를 가지고 있다. 무상태성과 비연결성이다. 무상태성은 말 그대로 상태를 가지지 않는다는 것인데, 상태를 가지고 있지 않음으로써 서버의 부하를 줄일 수 있다. 하지만 상태를 가지고 있지 않기 때문에 로그인 요청을 보낼 때 매번 인증된 사용자인지를 구별해야 한다. 이는 보통 토큰을 이용해서 구별한다. 비연결성은 한 번 연결을 시도하고 관련 요청에 대한 응답을 받고 마무리가 되면 연결을 종료한다는 것이다. 그럼 다시 요청을 보낼 때 연결을 시도하게 된다.
이런 두 가지 특성 때문에 발생하는 문제를 하나씩 해결해 나가면서 버전 이름이 추가되서 개발되어 왔다.
HTTP 1.0 에서는 단순히 html 텍스트 정보만 보내면 되었기 때문에, 무상태성과 비연결성으로 인한 문제가 크게 없었다. 하지만 점점 다양한 정보를 보내야 하는 상황에서는 한 번씩 정보를 주고받을 때마다 연결을 새로 맺고 하는 것이 점점 더 속도 문제로 다가왔다.
그래서 HTTP 1.1이 나왔고, 이는 한 번 연결을 시도하고 종료될 때까지 데이터를 여러번 주고 받고 다 주고 받고 나서 연결을 종료하는 특징이 있습니다. 이를 지속적 연결이라고 합니다. 또한 파이프라이닝을 통해서 첫 번째 요청을 보내고 응답을 받고 완료된 다음에 다음 요청을 보내는 것이 아니라 요청을 동시에 여러번 보낼 수 있게 되었습니다.
하지만 이 또한 이전 요청에 대한 응답이 늦어진다면 다음 요청을 처리할 수 없는 문제가 있어 HTTP 2.0에서 이런 문제를 스트림 다중화로 해결합니다. 이전 요청이 해결되지 않더라도 다음 요청을 수행할 수 있게 된 것입니다. 그리고 서버푸시를 할 수 있게 되서 서버에서 필요한 정보를 클라이언트에 먼저 보낼 수 있게 되었습니다.
하지만 HTTP 2.0 또한 TCP위에서 동작하기 때문에 신뢰성을 중시한 3way-handshake를 거쳐서 통신해야 되었기 때문에 기본적인 속도 문제를 완전히 해결하지는 못했습니다.
이에 구글에서는 QUIC 라는 프로토콜을 UDP 기반으로 속도를 해결하면서 신뢰성과 관련된 문제도 해결해서 HTTP 3.0 이라는 이름으로 제공을 하게 됩니다.
이렇게 HTTP라는 프로토콜은 웹 상에서 데이터를 주고받을 때 효율적으로 통신할 수 있도록 해주는 아주 유용한 프로토콜 입니다.
이런 HTTP 통신을 할 때는 요청 메세지를 보내고 응답 메세지를 받는데, 이런 메세지를 다시 세분화해보면 요청/응답 라인과 헤더와 본문으로 나눌 수 있습니다. 요청 라인에서는 요청 메서드와 HTTP 버전 등을 전달하고 응답 라인에서는 이에 따른 상태코드와 버전 등을 담아서 응답합니다. 헤더에는 HTTP 통신과 관련된 부가정보들을 담고 있고, 본문에는 통신과정에서 주고받는 실제 데이터가 담깁니다.
웹으로 사람들이 주고받는 정보가 많아짐에 따라 보안적인 문제도 많이 발생하였고, HTTP에서는 기본적으로 평문으로 주고 받기 때문에 중간에서 탈취할 수 있는 위험이 존재했습니다.
이에 SSL/TLS를 통해 HTTP와 TCP의 중간에서 보안적인 부분을 암호화를 통해서 해결합니다. 그리고 이를 HTTPS라고 간단하게 부르게 됩니다.
