[10분 테코톡] 달리의 WEB의 응답과 요청 과정 정리
브라우저 주소창에 주소를 입력하였을 때 어떠한 일이 일어나는지 살펴보자
그 전에 우선 택배를 보낸다고 가정했을 때 필요한 게 무엇일까? 우선 내용물을 담을 상자와 그것을 받을 사람의 주소 그리고 이름 그리고 받는 사람의 주소와 이름이 필요할 것이다.
이와 마찬가지로 웹에 데이터를 보낼 때도 받는 사람의 주소와 이름 그리고 보낸 사람의 주소와 이름과 그것을 담을 상자가 필요하다.
그렇다면 데이터를 보낼 때 주소에 해당되는 IP가 필요한데 보통 주소창에 데이터를 보낼 때 위와같이 도메인 이름을 적게된다. 그렇다면 브라우저는 이 도메인 이름만 받았을 때 어떻게 IP를 가져오게 되는 것일까?
이는 바로 클라이언트 브라우저에 도메인 주소를 입력했을 때 내부에 있는 소켓 라이브러리의 Resolver를 통해 OS에 요청을 하게 돼서 UDP IP 프로토콜을 통해 DNS 서버에 접속하여 IP를 가져오게 된다.
DNS란 도메인 네임시스템으로 브라우저에 주소를 입력하였을 때 가까운 DNS 서버에 접속을 하여 타고 타고 올라가서 매칭이 되는 IP를 가져오게 되는 시스템을 말한다. 이 과정을 통해서 IP주소를 얻게 되었고 이제 데이터만 보내면 된다.
그렇다면 이제 데이터를 보내기 전에 그 데이터를 보낼 터널을 연결해야 된다. 우리는 그것을 소켓이라고 부르는데 이 소켓은 클라이언트 브라우저에 있는 소켓 라이브를 통해 연결되게 된다. 클라이언트 브라우저가 다시 한번 OS에 프로토콜 스택을 TCP 프로토콜을 통해 서버에 연결하여 소켓을 연결하게 되는 과정을 거친다.
이때 소켓은 다음과 같은 것들이 필요하다. 첫번째로 디스크립터는 어플리케이션내에서 소켓을 식별하기 위한 요소이고 두 번째 포트 번호는 OS에서 소켓을 식별한다. 마지막으로 IP및 MAC 주소는 허브 및 라우터에서 소켓을 식별하기위해 필요한 것으로 이 세 가지를 통해 소켓을 식별하고 데이터를 담아 보내게 되는 과정이다.
그럼 소켓을 연결하는 과정을 알아보자. 우선 클라이언트에서 서버에게 SYN을 보낸다. 그러면 서버는 알았다는 의미의 본인의 SYN도 보내게 된다. 그러면 그것에 대해서 응답으로 다시 클라이언트에서 서버에 보내는 세가지 단계를 거쳐 소켓을 연결하게 된다.
그렇다면 이제 소켓이 연결되었는데 소켓에 많은 데이터를 한 번에 보낸다면, 그 과정에서 이 데이터가 말소되면 많은 데이터를 한 번에 또 다시 보내야 된다는 불상사가 생길 것이다. 때문에 데이터를 잘라서 보내게 된다.
자른 하나하나를 패킷이라고 부른다. 위 그림이 패킷의 구조이다. 가운데 보이는 데이터 조각에 해당되는 MSS가 Maximum Segment Size의 약자로 한 패킷에 담기는 데이터의 단위라고 생각하면 된다. 만약 보낼 데이터가 이 MSS가 클 경우에는 이것을 잘라 패킷에 담고 다음 데이터는 그 패킷을 잘라서 다음 패킷에 담아서 보내게 되는 과정을 거친다.
패킷은 다섯 가지 구조를 가지고 있다. MAC 헤더에는 허브에 필요한 정보를 담게 되고 두 번째 IP에는 라우트에 필요한 정보를 담게 된다. TCP 헤더에는 OS에서 필요한 정보를 담고 그 다음에 데이터를 담은 다음에 마지막으로 오류 감지를 위한 코드에 담아서 이 패킷을 보내게 되는 것이다.
클라이언트와 서버 측은 서로 많은 양의 패킷을 주고받을 건데 그렇다면 각각의 클라이언트와 서버가 서로 얼마나 많은 데이터를 받았고 또 얼마나 데이터를 보냈는지 아는 과정을 알아보려고 한다. 우선 클라이언트측이 처음에 데이터를 보낼 때 첫 번째 데이터를 의미하는 시퀀스 번호 1에 1460바이트를 보낸다고 가정해본다. 그렇다면은 서버 측에는 이제 1460바이트가 저장되게 되고 다음에 받을 것은 바로 1461번 바이트부터 받아야 돼 라는 의미로 ACK 번호 1461을 보내게 된다. 그러면 클라이언트측은 이것을 받고 나서 1461번째 데이터를 보내야 되는구나 하고 그 단계부터 다음 바이트를 보내게 된다. 그러면 서버 측에서도 데이터를 1460바이트에서 다음 바이트를 더한 2920바이트를 저장 하게 된다. 다시 ACK번호 2921을 보내서 다음 데이터인 2921바이트부터 필요하다는 것을 보내게 되면 마찬가지로 클라이언트측에서 그 번호부터 데이터를 보내서 서로 간에 얼마나 보냈는지 또 얼마나 받았는지를 확인하게 되는 과정을 거친다.
클라이언트측에서 데이터를 보낸 다음에 서버 측에서 다시 데이터를 받으려면 응답이 올 때까지 기다려야 된다. 이 과정을 패킷마다 반복을 한다면, 모든 패킷마다 이 대기 시간이 있으면 너무 과정이 길어지게 된다. 이것을 해결하기 위해 윈도우 제어 방식을 선택하게 된다. 윈도우 제어 방식은 서버가 수용할 수 있는 데이터 용량을 설정해놓고 그만큼의 데이터를 한 번에 받고 그 단위마다 응답을 보내게 되는 방식을 말한다.
윈도우 제어 방식은 서버측에서 클라이언트측에 '나는 이만큼의 정보를 받을 수 있어'라는 것을 먼저 공지한다. 그러면 클라이언트에서는 그 데이터를 기억해놓고 이 데이터 만큼 계속 정보를 보내게 된다. 그러다가 서버가 더 이상 받을 수 없겠구나를 알게 되면 클라이언트측은 대기를 하게 된다. 그러면 서버 측에서는 서버용 메모리 영역에서 그 데이터를 처리하고 받을 수 있는 영역을 확보하게 된다. 그 이후에 다시 클라이언트측의 응답으로 '난 이만큼 더 받을 수 있어'를 알리게 되고 이 과정을 반복하여 데이터를 주고받고 응답을 주고받는 횟수를 줄여 효율적인 송수신을 하게 되는 것이다. 이 과정을 통해 데이터를 다 보냈다.
모든 데이터를 주고 받았으니 소켓을 끊는 과정이 필요하다. 이 단계는 단순하게 클라이언트측과 서버 측이 서로 난 보낼 거 다 보냈어 너는 다 보냈니?라고 묻는 과정이라고 생각하면 된다.
우선 서버 측에서 '나는 할 일 다 끝냈어' 라는 의미의 FIN을 보내게 되면 클라이언트측에서 '알았어' 라고 대답을 한다. 그 이후에 '나도 끝났어' 라고 클라이언트가 말하게 되면 '너 끝났구나'라고 알리는 과정의 네 가지 단계를 거치게 된다.
소켓 연결 단계는 세 가지 단계를 거치기 때문에 3 hand shake라고 부르게 되고 연결을 끊는 과정은 네 단계를 거치기 때문에 4 hand shake라고 부르게 된다.
이 긴 과정을 요약해보자면 우선 클라이언트의 주소창에 입력했을 때 소켓 라이브러리의 Resolver를 통해 OS에 요청을 하게 되고 UDP IP 프로토콜을 통해 DNS 서버에 접속하여 IP를 가져온다. 이 IP를 통해 다시 OS의 프로토콜 스택에 있는 TCP IP 프로토콜 통해 서버에 접속을 하여 데이터를 송수신하게 되면서 이 긴 과정이 마치게 되는 것이다.
*참고 : [10분 테코톡] 칙촉의 TCP/UDP 정리
참고
https://www.youtube.com/watch?v=y8j59bEy4kQ&ab_channel=%EC%9A%B0%EC%95%84%ED%95%9C%ED%85%8C%ED%81%AC