[인강/윤성우/TCP/IP 소켓 프로그래밍] TCP기반 서버/ 클라이언트

TCP와 UDP에 대한 이해

 

TCP/IP 프로토콜 스택

- 인터넷 기반의 데이터 송수신을 목적으로 설계된 프로토콜 스택

- 큰 문제를 작게 나눠서 계층화 한 결과

- 7계층을 세분화가 되며, 4계층으로도 표현함

 

4계층 '애플리케이션 -> TCP/UDP (전송)-> IP(라우터, 인터넷) -> LINK(네트워크 엑세스)

7계층 '애플리케이션 -> 표현 -> 세션 -> 전송 -> 네트워크 -> 데이터 링크 -> 물리 계층

 

4계층

Link 계층 : 물리적인 연결 (라우터 자체는 물리계층)

Ip 계층 : 라우팅(경로설정)은 ip 계층 --> 이 단계만 되어도 물리적, 논리적 연결이 가능함

전송 계층 : 데이터를 어떻게 보낼 것 인가.

어플리케이션 계층

 

IP만으로도 데이터를 주고 받는 것은 가능하다.

 

프로그래머에 의해서 완성되는 application 계층

- 응용프로그램의 프로토콜을 구성하는 계층

- 소켓을 기반으로 완성하는 프로토콜을 의미함

- 소켓을 생성하면 link,ip,tcp/udp 계층에 대한 내용은 감춰진다.

- 응용 프로그래머는 application 계층의 완성에만 집중하면 된다.

 

tcp기반 서버, 클라이언트의 구현

 

tcp 서버의 기본적인 함수 호출 순서

socket(소켓생성) -> bind (소켓에 주소할당)-> listen(연결요청 대기상태) -> accept(연결허용) -> read/write -> close

 

서버측 >>

listen 함수를 통해서 소켓을 listen socket으로 지정하는 셈. 

listen socket이 하는 일은 지정된 socket을 이용해서 연결요청을 대기 큐에 전달하는 역할을 한다.

listen socket은 실질적인 연결(서비스)를 제공하진 않음. 단순히 대기 큐에 등록해주는 역할

추가적인 소켓이 생성되면서 연결이 되는 상황은 accept 함수가 호출 됐을 경우다. accept 함수에서 listen socket을 인자라 받는 이유는 listen socekt 과 연결요청 대기큐가 쌍을 이루기 때문입니다. (listen socekt이 두개면 대기큐도 두개가 된다) 

 

!! 소켓 프토번호에 관해서

소켓은 기본적으로 중복된 포트번호를 갖을 수 없다. 왜냐하면 외부로 부터 접속 할 때 포트번호는 어떤 소켓에 접속 될지 결정하는 요소가 이기 때문이다.

그러면 Listen scoekt 포트가 80이라면 클라이언트는 서버 ip + listen 포트로 접속 요청을 하게 된다. 클라이언트는 물리적으로 다르기 때문에 다른 클라이언트도 같은 80포트로 접속하는 소켓을 갖는 건 문제가 되지 않는다.

그렇다면 accept를 통해 실질적으로 클라이언트와 통신하게 되는 소켓은 어떤 포트를 갖을까?

정답은 accept로 인해 생성된 소켓은 인자로 넣어준 listen socket의 포트번호가 맵핑된다. 프로그래머가 임의로 같은 포트를 지정할 순 없지만 이 경우엔 운영체제에 의해 맵핑 되기 때문에 가능하다.

그렇다면 클라이언트가 다수 연결이 되면 다수의 동일한 포트(listen socket 포트와 같은)의 소켓이 존재하게 되는데 이때 클라이언트 소켓과 서버측 소켓은 어떻게 맵핑 되는걸까? 이떄는 단순히 포트 번호로만 맵핑하는 것이 아니라 ip 주소까지 확인하여 적절한 socket으로 read/write를 하게 된다.

 

클라이언트측>>

socket -> connect -> read/write -> close

 

Iterative 기반의 서버, 클라이언트 구현

데이터의 경계가 존재하지 않기 때문에 read 와 write 함수의 사용시 유의.

윈도우와 리눅스의 차이점 : read/write 대신 send/recv, WSAStarup 과 같은 윈속 라이브러리 로드 필요.

 

데이터를 어떻게 주고 받고 해석할지를 프로그래밍 하는 것이 어플리케이션 프로토콜이다.

 

TCP 소켓에 존재하는 입출력 버퍼

wrtie read 되는 상황이 실제로 쓰고 읽는 상황이 아니라 write 되면 출력버퍼에 데이터를 전달하고 이를 tcp 프로토콜에 근거해서 물리적인 전달이 이루어진다. 이와 같은 버퍼 때문에 슬라이딩 윈도우 프로토콜(패킷 흐름제어)이 적용 가능하다.

 

TCP의 내부 동작 원리

- 상대 소켓과의 연결 : 3way handshaking

소켓 a : hey socket B bro, 할말 있으니까 연결 좀 하자

소켓 b : okay bro. I am ready.

소켓 a : okay thanks

 

- 데이터 통신 : ack = seq + 전송된 bytes + 1 => 이 값을 통해 데이터를 완전히 받았는지 아닌지 확인 가능.

 

- 연결 정료 : 4way handshaking (일반적인 종료로 인한 데이터의 손실을 막기 위함)

소켓 a : 연결 끊으려는데..

소켓 b : 어 잠시만

소켓 b : okay 끊으세요.

소켓 a : okay bye~