Webserver 와 채팅 서버를 구현하면서 TCP 소켓, 웹 소켓을 모두 다뤄봤지만 정확한 차이와 개념을 공부해보자,,
OSI 7계층
-
우선 TCP/IP 소켓과 web소켓이 동작하는 layer가 다르기 때문에 OSI 7계층에 대한 이해가 필요하다
-
OSI 모델이란?
네트워크 통신을 위한 표준 규격 (ISO 국제표준화기구에서 정의함)
TCP의 구조
- TCP로 전송할 때 붙이는 헤더를 TCP 헤더라고 하고, 이 TCP 헤더가 붙은 데이터를 세그먼트라고 한다.
- TCP로 데이터를 전송하려면 먼저 연결(connection)이라는 가상의 독립 통신로를 확보하여 연결을 확립해야 한다.
- TCP의 연결은 3way-handshake 과정을 통해 수립된다
- 초기값은 0이고 비트가 활성화되면 1이 된다, 연결을 확립하려면 SYN(연결 요청), ACK(확인 응답)가 필요하다.
3-way handshake
- 데이터를 전송한 후에도 연결을 끊기 위한 요청을 교환해야 한다.
일련번호와 확인 응답 번호의 구조
- 3-way 핸드셰이크 이후 데이터 전송에 사용되는 TCP 헤더의 일련번호와 확인 응답 번호
1. 일련번호와 확인 응답 번호
- TCP는 데이터를 분할해서 보내는데
일련번호는 송신 측에서 수신 측에 이 데이터가 몇 번째 데이터인지 알려주는 역할을 한다. 확인 응답 번호는 수신 측이 몇 번째 데이터를 수신했는지 송신 측에 알려주는 역할을 한다. 예를 들어 10번 데이터를 수신하면 11번 데이터를 송신 측에 요청한다. 이를 확인 응답이라고 한다.
→ 일련번호와 확인 응답 번호를 사용해서 데이터가 손상되거나 유실된 경우에 데이터를 재전송하는데 이를 재전송 제어 라고 한다.
2. 윈도우 크기
- 1의 통신방식은 세그먼트(데이터) 하나를 보낼 때마다 확인 응답을 한 번 반환하는 통신이다.
- 이와 같은 통신은 한 번 보낼때마다 한 번 응답을 반환하는 방식이라 효율이 높지 않다.
- 따라서 매번 확인 응답을 기다리는 대신 세그먼트를 연속해서 보낸 후 확인 응답을 반환하도록 하고, 받은 세스먼트를 일시적으로 버퍼에 보관한다.
- 만약 수신 측이 대량의 데이터를 받는다면 버퍼에 오버플로우가 발생한다. 따라서 버퍼의 한계 크기를 알고 있어야하는데 그것이 TCP헤더의 윈도우 크기이다.
- 이 윈도우 크기의 값은 3-way handshake시에 판단한다.
포트 번호의 구조
1. 포트번호
- 전송된 데이터의 목적지가 어떤 애플리케이션인지 구분하는 번호
- TCP헤더의 출발지 포트번호와, 목적지 포트번호가 필요하다.
- 포트번호는 0 ~ 65535번을 사용한다, 0 ~ 1023번은 잘 알려진 포트라고 하고 1025번 이후는 랜덤 포트라고 한다.
TCP통신에서는 소켓을 이용한 연결방식을 사용한다. 그로인해, 양방향 통신이 가능하게 되는데 양방향 통신이란, 클라이언트단과 서버단이 한번의 연결(connection) 확립 후 서로에게 요청을 보내 통신을 할 수 있게 해주는 것이다. (서버 -> 클라이언트, 또는 클라이언트 -> 서버) 또한, 클라이언트단과 서버단의 연결이 끊어지지않고 계속 연결을 유지해주어 실시간 소통이 가능하다.
소켓이란??
일반적으로, 서버는 특정 컴퓨터 위에서 돌아가고 특정 포트넘버에 할당된 소켓을 갖는다. 이 서버는 클라이언트가 커넥션 요청을 만들기 위한 소켓을 리스닝하며 기다린다.
클라이언트 쪽에서, 커넥션이 성립된 경우, 소켓이 성공적으로 생성되며 클라이언트는 소켓을 서버와 상호작용하기 위해 사용할 수 있다.
소켓이란 네트워크 위에서 돌아가는 두 프로그램 간의 양방향 통신링크의 엔드포인트입니다. 소켓은 포트 넘버를 할당받아 TCP 레이어가 데이터의 목적지인 애플리케이션을 식별하도록 합니다. 엔드포인트는 IP 주소와 포트넘버의 조합이다.
즉 소켓은 엔드포인트. 즉 IP와 포트 넘버를 활용하여 만들어진 통신의 양 끝이다. 우리가 보통 웹서버를 만들때 80포트를 이용해서 만드는데, 이때 쓰는 엔드포인트도 IP + 포트 의 조합으로 소켓을 통한 통신을 하게된다.
HTTP통신
- 해당 그림을 보면 Http 통신은 TCP위에서 동작하는 것을 알 수 있다.
- HTTP통신은 TCP통신과는 다르게 단방향 통신이다. 즉, http통신은 클라이언트의 요청이 있을때만, 서버단이 응답하고 처리를 해주며 해당 응답이 끝나면 연결을 바로 끊게 된다.(HTTP1.0기준) 즉 서버에서 클라이언트로 먼저 요청을 보낼 수 없다.
- HTTP통신은 TCP를 거쳐야 하니, 3-way handshake의 과정을 거치는 통신이며 TCP에서 소켓을 사용하여 연결과 끊음을 진행한다. 데이터를 전송하는 과정은 7계층에서 이루어지며, 이 과정에서도 TCP에서 사용하던 소켓을 이용한다.
위에서 TCP소켓 통신은 양방향 통신이며 실시간 통신이 가능하다고 했는데 왜 http통신은 단방향이 되는 것일까?
TCP통신이나 HTTP통신이나 데이터를 전송할 때 소켓이 사용되는것은 동일한데. 우선, HTTP통신이 소켓 기반인 이유는 애초에 HTTP는 TCP에 기반하여 만들어졌기 때문이다. 그렇기에, HTTP통신은 3-way handshake를 거치고 데이터 전송에도 동일한 소켓이 사용되는데, 이때 데이터전송에 사용되는 소켓의 통신방식이 TCP통신의 데이터전송에서 사용되는 소켓통신과는 다른 방식으로 사용이 된다. HTTP통신은 클라이언트-서버 모델로 클라이언트가 요청을 보내고 서버가 응답하는 형태로 이루어진다. 즉 서버는 클라이언트의 요청이 있을 때에만 클라이언트에게 데이터를 전송할 수 있는 것이다. (양방향 통신이라고 말할 수 있으려면 서버도 클라이언트에게 별도에 요청이 없을 때에도 데이터 전송이 가능해야 한다.)
양방향 통신을 위해서 소켓을 사용하도록 하는 프로그래밍을 소켓 프로그래밍이라 했는데, 반대로 HTTP통신을 하기 위한 프로그래밍을 HTTP 프로그래밍이라고도 한다. 하지만, HTTP 통신에서도 소켓을 사용한다고 했으니 꼭 소켓을 사용한다고 해서 소켓 프로그래밍이라고는 하지 않는다. 즉, 해당 소켓이 어떠한 용도로 사용되느냐에 따라 HTTP 프로그래밍이 될 수도 있고, 소켓 프로그래밍이 될 수도 있는것이다.
Web Socket
기존의 HTTP통신은 connectionless로 기본적으로 연결이 유지되지 않으며 단방향이라는 특징을 갖고있다. 그렇기에 이를 극복하고 양방향이면서 실시간 통신이 필요한 기능들에 대해 여러가지 시도들이 있었다.
대표적으로, http polling, http streaming등이 시도되었다. 하지만, 비효율적이며 HTTP통신에서의 한계점 때문에 다른 대안이 제시되었다.
Http Polling
- 가장 기본적인 데이터 처리방식으로, 특정 주기를 가지고 서버에 http request을 하는 방식이다
- Polling 방식은 언제 통신이 발생할 지 예측이 불가능하기 때문에 클라이언트가 평범한 http request를 일정한 주기로 서버에 요청하여 이벤트 내용을 전달받는 방식이다.
- 하지만 클라이언트가 요청을 지속적으로 보내기 때문에 클라이언트가 많아지면 서버의 부담이 급증하게 된다.
- 실시간 통신이라고는 하지만 실시간 정도의 빠른 응답을 기대하기는 어렵다.
Http Streaming
- 일반적인 TCP Connection과 비슷하며, 클라이언트와 서버간 연결 된 연결 통로로 데이터를 보내는 방식이다
- 서버에서 클라이언트로 이벤트를 전달할 때, 해당 요청을 끊지 않고 필요한 메세지만 보내기를 반복하는 방식이다. 서버에서 메세지를 보내고 나서 다시 http request연결을 하지 않아도 되어 Long Polling에 비해 부담이 덜 하다.
한계점
두가지 방법 모두 Http를 통해 통신하기 때문에 요청과 응답시 둘 다 Header가 불필요하게 크다는 단점이 있다.
또한 Streaming 방식의 경우 서버에서 클라이언트로 메세지를 보낼수는 있지만 클라이언트에서 서버로 메세지를 보내는것에는 조금 어렵다는 문제점이 있다.
따라서 Http 환경에서 클라이언트와 서버간에 어려움 없이 양방향으로 통신이 가능하게 하기 위해서 HTML5 표준의 일부로 WebSocket이 만들어지게 되었다. (TCP 기반의 어플리케이션에선 그냥 TCP 소켓으로 양방향 통신 채팅서버 구현 가능 ex: IRC 서버)
웹 소켓은 일반 소켓(TCP 기반 소켓)처럼 양방향에 실시간 통신이 가능하며, IP와 포트를 사용한 통신을 한다는점에서 공통점을 갖고 있다. 하지만, 웹 소캣은 기본적으로 HTTP 기반 계층(7 layer)에서 작동한다는점에서 일반 소켓이 TCP 기반 계층(4 layer) 에서 작동한다는 점에서 다르다. 따라서 WebSocket과 TCP Socket은 엄연히 다른 것으로 보아야 한다.
웹 소켓을 기반으로 하는 통신은 WebSocket 프로토콜이라는 새로운 규약에서 이루어진다. 하지만, 웹 소켓 통신을 위한 별도의 포트는 없으며 포트 80,443(http:80, https:443)을 사용하도록 설계되어져 있다. 그렇기에 HTTP 프로토콜, HTTPS 프로토콜과도 호환이 되도록 설계되어져 있다고 하는 것이다.
WebSocket 프로토콜은 최초 접속시 HTTP, HTTPS 위에서 TCP connection을 거치고 그 이후에 웹 소켓을 이용해야하는 경우에 HTTP Upgrade header라는 걸 사용하여 HTTP 프로토콜에서 혹은 HTTPS 프로토콜에서 WebSocket 프로토콜로 전환시킨다.
따라서, WebSocket 프로토콜이 HTTP 프로토콜을 대체하는 개념은 아니고 상호보완하는 개념으로 볼 수 있다.
참고
