: 소켓 = application developer가 작성하는 application 프로그램과 OS가 컨트롤하는 transport 계층 사이의 인터페이스
: 소켓 프로그래밍은 tansport를 부탁할 때는 UDP,TCP 한테 부탁할 수 있음.
UDP
UDP를 사용하는 경우!(connection 셋업하지 않는 것)
: 각 data마다 IP 목적지 주소와 port번호 붙여서 보내주게 된다.
: 서버의 경우에는 프로그래머가 명시적으로 port번호를 지정한다. 따라서 server의 포트번호는 알려져있지만 client의 port번호는 알려져있지 않다.
: 그렇다면 서버 쪽에서는 클라이언트의 ip 주소와 port 번호 어떻게 아는가? => 자기가 받은 segment로부터 정보를 extract 해낸다.
전체적인 flow는 다음과 같다.
: 서버 process는 실행되기 시작하면 서버 socket을 create한다.
: 서버는 이 socket을 통해서 데이터를 내보내고 받는다.
: client 측에서도 통신을 위해서 클라이언트 socket을 create한다.
: 그리고 client가 서버의IP주소와 서버 소킷의 port 번호 가지고 메시지에 붙여서 client 소켓을 통해서 정보를 내보낸다.
: 서버의 IP 주소와 port 번호는 명시적으로 알려져있다!(그래서 위의 과정이 가능해짐)
: 그렇다면 서버는 network를 통해 전달된 client 소켓을 이 서버 소켓을 통해서 읽어들인다.
: 그리고 서버 소켓 써서 reply를 쓴다. 근데 어느 client로 갈지 클라이언트의 ip주소와 port번호를 명시해주어야한다. 이것을 어떻게하면 알아낼 수 있는가?
: client쪽 UDP가 해당 정보를 붙여놨으므로 extract해서 알아낼 수 있다.
: 과정이 끝나고 client 소켓은 닫지만, 서버소켓은 열어놔야한다.
TCP
: door 소켓을 만들어놓는다 (서버는)
: client 프로그램 실행되면 tcp socket만들고, handshake를 한다. 이때 hand shake를 위해서 컨텍할 서버의 ip주소와 port 번호를 명시해준다.
: client 소켓을 create하면서 클라이언트 쪽 TCP가 서버 쪽 TCP와 커넥션을 맺게 된다.
: 서버는 해당 client와만 소통할 socket을 새로 create한다. (목적지 명시 안해줘도 되겠지)
: 해당 과정으로 인해 TCP는 커넥션 별로 socket을 여러개 갖고 있게 된다.
: 이런 door 소켓과 client별 socket이 필요한 이유? == byte stream을 교환하는 것이기 때문에!
: UDP는 각 메시지가 독립적이다. (메시지 받으면 답 하나 보내주면 됨)
: 근데 TCP는 byte-stream을 주고받을 수 있게 되는데, 이 과정 동안 다른 client의 메시지를 못받으면 안되니까! client별 소켓이 필요하다.
: 서버 실행 시작하면 소켓 하나 만든다. (서버 소켓)
: 소켓에 port번호 명시적으로 지정해준다.(binding 해준다.)
: connection request가 들어오면, 서버 소켓.accept()를 실행해서 새로운 소켓을 만들어준다. (=커넥션 소켓)
: 그러면 client와 connection setup이 완료되는 것이다. (= 커넥션 소켓이 서버 쪽에 만들어졌다.)
: 그 다음에는 UDP와 비슷한 방식으로 메시지를 주고 받는다.
: 마찬가지로 커뮤니케이션이 끝나면 connection socket과 client socket을 close한다.
