프로토콜
해당 내용은 김영한 강사님의 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 정리한 내용입니다. 개인적으로 이해한 부분도 있는데, 틀린 내용이면 지적부탁바랍니다. 그리고 김영한 강사님의 강의 이미지가 너무 좋아서 설명을 위해 작성을 하지만 문제가 있다면 댓글 남겨주시면 해당 내용은 수정하도록 하겠습니다.
IP 프로토콜
인터넷 프로토콜은 지정한 IP 주소에 데이터를 전달하는 것이다. 위의 예시에서는 100.100.100.1에서 200.200.200.2로 데이터를 전송하는 상황이다. 데이터는 특정한 chunk로 나뉘어져서 전송이 되는데 그것을 packet이라고 하고 packet 단위로 데이터를 주고 받는다.
데이터를 주고 받을 때에는 IP packet을 사용하는데, 그곳에는 출발 지점의 IP, 도착 지점의 IP, 기타 값들이 포함되어있다. 그렇게해서 인터넷 서버 노드 한 곳에 데이터를 던져주면 서버 쪽으로 거쳐가며 이동한다. 그리고 서버는 응답을 받으면 인터넷 망에 성공했던 실패했건 응답 메세지를 클라이언트로 다시 보내게 된다.
그런데 이런 IP프로토콜이 완벽한 것일까?
IP 프로토콜의 한계
이 상황에서의 가정에는 몇 가지 문제점이 있다. 아래의 질문에 대해서 잠깐 고민을 해보자.
1. 패킷을 받을 대상이 없는 경우에는 어떻게 해야할까? 분명히 클라이언트는 서버가 작동 중일 것이라고 생각하고 packet을 인터넷에 던졌는데, 서버가 죽어있어서 수신을 하지 못한 경우가 있을 것이다. 데이터를 보내기 전에 서버가 살아있는지 죽어있는지 어떻게 알 수 있을까?
2. 중간에 노드들을 거쳐가며 데이터가 이동하는데 그 노드 사이의 연결이 물리적인 사고로 끊겨서 데이터가 소실될 수도 있다.
3. 패킷이라는 단위로 날라가는데, 한번의 패킷에 모든 정보가 날라가는 것이 아니라 패킷이 수용할 수 있는 최대 크기가 있어서 그 이상인 경우에는 여러 패킷을 보내서 서버에서는 조합해야한다. 그런데 나는 1번 패킷, 2번 패킷 순서로 보냈는데 서버는 2번 패킷, 1번 패킷 순서로 받아서 조합해버리면?
4. 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 여러 개면 이걸 어떻게 구분해야할까? 그러니까 알파벳에서 구글 서버도 돌리고 유튜브 서버를 같은 IP 주소를 사용한다고 생각해보자. 그러면 IP주소를 목적지로 IP패킷을 보내버리면, 어떤 곳의 내용인지 구분을 할 수 있을까?
PORT
위에서 언급한 문제의 대부분을 해결해주는 것이 TCP 프로토콜인데, TCP 프로토콜을 이해하려면 PORT에 관한 이해가 우선 필요할 것 같아서 순서를 바꿨다.
일반적으로 컴퓨터가 작동하고 있을 때에는 위의 그림처럼 각각의 클라이언트, 서버가 하고 있는 일이 하나가 아니라 여러 개인 멀티 프로세스 환경일 확률이 높다. 그러면 OS는 해당 프로세스에 대해서 PID(프로세스 ID)를 할당해준다. IP 프로토콜에서 부족했던 여러 어플리케이션이 돌아가는 상황에서 목적지를 구분하는 것을 이 PID로 하고 PORT라는 이름으로 보낸다.
그래서 TCP 프로토콜에서 다시 설명을 하겠지만 TCP 패킷에서 클라이언트가 서버에게 출발지의 IP와 PORT, 도착지의 IP와 PORT 정보를 가지고 패킷을 전송을 한다. 그러면 서버에서 해당 PORT번호와 같은 PID로 접근을 해서 데이터를 넘겨주고 받았다고 클라이언트에게 메세지를 다시 보내줘야겠구나하고 받은 패킷에 있던 출발지 IP와 PORT를 목적지 IP와 PORT로 그대로 적어서 다시 응답 메세지를 보내준다.
일반적으로 운영체제를 부팅 시키는 순간에 OS를 유지하기 위한 프로세스가 1,2번으로 고정되는 것처럼 (물론, OS마다 다를 수는 있겠다..) PORT에도 일반적으로 이 번호는 이 어플리케이션이 사용할 거에요하고 정해놓은 포트 번호가 있다.
일반적으로 프로세스는 0번부터 65535까지 할당이 가능하기에 PORT번호는 해당 번호까지 사용이 가능하다. 하지만 0번부터 1023번까지는 잘 알려진 포트 번호로 사용돼서 웬만해서는 안 쓰는게 좋다. FTP - 20,21, TELNET - 23, HTTP - 80, HTTPS - 443 같이 번호가 있으니... 이건 심심하면 나중에 찾아봐야겠다.
TCP(Transmission Control Protocol)
다른 것에는 약자의 의미를 적지 않았는데, TCP는 적었다. 그 이유는 TCP는 위에서 언급한 모든 IP 프로토콜에서 생길 수 있는 문제점을 해결해준다. 우선 TCP가 추가됨으로써 클라이언트에서 서버로 패킷을 보낼 때 어떤 점이 추가되는지부터 알아보자.
기존에는 출발지 IP, 도착지 IP, 기타 정보만 담겨서 보내졌지만, TCP 패킷을 함께 보내면, 그곳에는 출발지 PORT와 도착지 PORT, 전송 제어, 전송 순서, 검증 정보 같은 내용이 추가가 된다. 이러한 내용의 추가로 이전에 IP프로토콜에서 설명했던 데이터가 손실되거나, 서버에서의 문제로 패킷이 원래 의도와 다른 순서로 도착하는 문제, 여러 어플리케이션에서 돌아갈 때의 문제를 해결해준다.
또한 TCP는 위와 같은 패킷 데이터의 추가뿐만 아니라 3 way handshaking을 통한 방식으로 상대 서버가 죽었는지 살았는지와 데이터를 보낼 수 있는지를 확인한다. TCP 프로토콜은 클라이언트가 서버와 연결을 할 때에 SYN이라는 접속 요청 메세지를 우선 보낸다. 그러면 서버는 ACK라는 요청 수락 메세지와 함께 SYN으로 클라이언트에게 접속 요청 메세지를 보내고 클라이언트는 해당 메세지를 받아서 다시 서버한테 ACK를 보낸다.
복잡해보이지만 장점은 확실하게 connect가 되었는지 확인을 할 수 있다. 컴퓨터 네트워크 시간에 특정 데이터 패킷이 몇 개로 나뉘어져있고 TCP일 때 UDP일 때 차이를 설명하라는 문제를 풀어보면 알겠지만, 저건 패킷마다 일어나는 것이다. 이게 단점이지만 확실하다.
추가적으로 순서와 관련돼서는 전송 순서를 받는다고 하는데 어플리케이션에서 어떻게 최적화를 하는 방법이 있겠지만, 일반적으로 순서대로 들어왔다면 그 순서대로 받은 부분까지만 놔두고 나머지는 전부 버리고 다시 그 이후 번호들부터 보내라는 메세지를 보낸다.
예를 들어보면 1,2,3번 패킷을 클라이언트에서 서버한테 보냈는데 서버는 1,3,2번 순서로 패킷을 받았다고 해보자. 그러면 서버는 2,3번 패킷을 모두 버리고 클라이언트에게 2번 패킷부터 나머지 다시 보내라는 메세지를 날린다. 기본적으로 이렇게 문제를 해결한다.
UDP 프로토콜
이 부분은 간단하게 설명하면, TCP에서의 3 way handshake 부분이 빠지고 데이터 전달 보증과 순서 보장 모두가 빠진 방식이다. 그러면 단점이지 않냐하는데 어떻게 최적화가 많이 일어나서 요즘에는 많이 사용한다고 한다.
HTTP3.0인가? 아무튼 특정한 HTTP 버전에서 과정에서 낭비되는 시간이 많으니까 최적화를 위해서 3 way handshaking과정에서 일어나는 클라이언트에서 다시 서버로 ACK 보내는 과정에 한꺼번에 원래 보내려는 데이터까지 같이 보내는 등 이렇게 최적화를 시키려고 노력하는데 아예 UDP로 바꿔버리는 그런 방식을 채택하고 어플리케이션 단에서 책임지는 방식으로 문제를 해결하려고 하는 것 같다.
DNS(Domain Name System)
IP를 사용하면 확실하게 구분하고 컴퓨터가 이해하는데에는 적합한 방법이다. 하지만 우리는 google.com 같은 기억하기 쉬운 Domain으로 기억하지 google.com의 IP를 기억하지는 않는다. 그래서 인터넷에서는 DNS라는 부분이 있는데 이것은 Domain과 IP의 매핑 찾아주는 데이터베이스 같은 공간이라고 생각을 하면 된다. DNS는 계층적 구조를 가지고 있는데 해당 계층은 다음과 같다.
주소창에 google.com이라는 것을 친다고 하면 TLD쪽에서 해당 Domain을 관리하고 있는 레벨의 DB에서 해당 내용을 찾아서 하단으로 연결을 계속 해준다. 이 정도만 이해하면 괜찮지 않을까 싶다...
이게 원래는 Root level에 한꺼번에 모든 요청이 들어오면 힘드니까 이렇게 계층적 구조로 있고 이용객이 많은 특정 서버는 여러 IP주소에 대해서 나눠가지고 실제 DNS서버에 등록할 때에 진명이니 그런 게 있는데 솔직히 시험을 보는게 아닌 이상 이 정도까지 알아야하나 싶다.