Networking - What is a socket?

http://beej.us/guide/bgnet/html/multi/theory.html

2. What is a socket?
너는 항상 소켓이란 말을 듣는다. 그리고 아마도 너는 그것들이 정확히 무엇인지 궁금해하고 있다. 음, 그것들은 이것이다 : 표준 Unix file descriptor를 사용하여 다른 프로그램에게 말하는 방법.

뭐?

그래 - 너는 Unix hacker가 말하는 것을 들었을지도 모른다 "음, 유닉스에 있는 모든 것은 파일이다!" 그 사람이 말하고 있는 것은, 유닉스 프로그램이 일종의 I/O 처리를 할 때, 그들은 파일 디스크립터를 읽거나 거기에 써서 그것을 한다. file descriptor는 간단히 열려있는 파일이 한 정수와 사상된 것이다. 그러나 (여기가 중요하다), 그 파일은 네트워크 연결이 될 수 있고, FIFO, pipe, 터미널, 디스크 파일에 있는 것, 또는 어떤 다른 것이든 될 수 있다. Unix에 있는 모든 것이 파일이다! 그래서 너가 다른 프로그램과 인터넷에서 의사소통 하고 싶을 때, 너는 file descriptor를 통해 그것을 할 것이다. 너는 그것을 믿는게 더 나을 것이다.

"내가 어디서 네트워크 소통을 위해 이 file descriptor를 얻나요?"라는 것은 지금 당장 너의 머리속에 있는 마지막 질문이지만, 나는 그것을 어쨋든 대답할 것이다: 너는 socket() 시스템 루틴에 대한 호출을 만들어야 한다. 그것은 socket descriptor를 반환하고, 너는 특수화된 send()와 recv() 소켓 호출을 사용하여 그것을 통해 의사소통 한다.

"그런데, 이봐" 너는 지금 당장 외치고 싶을지도 모른다. "만약 그것이 file descriptor라면, 해왕성의 이름에서 왜 내가 소켓을 통해 의사소통하기 위해 일반적인 read() 와 write() 호출을 사용할 수 없는가?" 그 간단한 대답은 "너는 할 수 있다" 이고. 더 긴 답은 "너는 할 수 있지만, send()와 recv()는 너의 데이터 전송에 대한 더 큰 통제력을 제공한다" 이다.

다음은 무엇인가? 이것은 어떤가 : 모든 종류의 소켓들이 있다. DARPA 인터넷 주소 (인터넷 소켓), local node에 있는 경로 이름(Unix Sockets), CCITT X.25 주소 (X.25는 너가 안전하게 무시할 수 있는 소켓이다.), 그리고 아마도 너가 작동시키는 어떤 Unix 버전에 맞는 다른 것들. 이 문서는 오직 처음것만 다룬다. : Internet Socketes

2.1 Two Types of Internet Sockets
이게 무엇인가? 인터넷 소켓의 두 가지 종류가 있다고? 그렇다. 음 아니야. 나는 거짓말하고 있어. 더 많이 있지만, 그러나 나는 너를 겁주고 싶지 않다. 나는 여기에서 두 가지 종류에 대해서 이야기할 것이다. 이 문장을 제외하고, 나는 너에게 "Raw Sockets" 또한 매우 강력하고 너는 그것들을 봐야한다고 말할 것이다.

좋아 이미. 그 두 가지 종류가 무엇인가? 하나는 "Stream Sockets"이고; 다른 하나는 "Datagram Sockets"이다. 그리고 이후로, 개별적으로 "SOCK_STREAM과 "SOCK_DGRAM"으로 언급되어질 것이다. datagram sockets은 가끔씩 "connectionless sockets"으로 불려진다. (만약 너가 원하면 그것들이 connet()되어질 수도 있찌만. 아래에서 connet()를 보아라)

Stream sockets들은 신뢰할만한 두 방향으로 연결된 커뮤니케이션 스트림들이다. 만약 너가 두 아이템을 순서 "1, 2"로 소켓에 만들어 낸다면, 그것들은 반대편에 순서 "1, 2"로 도착할 것이다. 그것들은 또한 에러가 없을 것이다. 나는 사실, 확신한다. 그것들이 에러가 없다고. 만약 다른 사람들이 아니라고 주장한다면 나는 귀를 막고 찬송가를 부를 것이다.

무엇이 stream sockets들을 사용하는가? 음, 너는 telnet 프로그램을 들은적 있는가, 그래? 그것은 stream socket을 사용한다. 너가 타이핑하는 모든 문자들은 너가 그것들을 타이핑하는 같은 순서로 도착할 필요가 있다. 맞지? 또한 웹브라우저들은 페이지를 얻기위해, stream sockets들을 사용하는 HTTP protocol을 사용한다. 정말로, 만약 port 80에서 너가한 웹사이트에 telnet하여, "GET / HTTP/1.0"으로 치고 RETURN 두 번 치면, 그것은 너에게 HTML을 다시 보내줄 것이다!

어떻게 stream sockets들은 데이터 전송의 고수준을 달성하는가? 그것들은 "Transmission Control Protocol", TCP라고 알려진 통신 규약을 사용한다. (RFC793을 보아라 TCP에 대한 세부 정보를 보려면) TCP는 너의 데이터가 순차적으로 에러없이 오도록 해준다. 너는 이전에 "TCP"를 들었을지도 모른다. "TCP/IP"의 더 좋은 절반으로서, 여기에서 "IP"는 "Internet Protocol"을 상징한다. (RFC 791)을 보아라. IP 주로 인터넷 라우팅을 다루고, 일반적으로 data integrity에는 책임이 없다.

좋아. Datagram socket은 어떤가? 왜 그것들은 connectionless라고 불리는가? 여기에서 중요한 것이 무언인가? 왜 그것들은 신뢰할 수 없는가? 음, 여기에 몇 가지 사실들이 있다: 만약 너가 datagram을 보낸다면, 그것은 도착할지도 모른다. 그것은 순서없이 도착할지도 모른다. 만약 그것이 도착한다면, 패킷내의 데이터는 에러가 없을 것이다.

Datagram 소켓은 또한 라우팅을 위해 IP를 사용한다. 그러나 그것은 TCP를 사용하지 않는다. 그것은 "User Datagram Protocol", 또는 UDP를 사용한다. (RFC 768을 보아라)

왜 그것들은 connectionless인가? 음, 기본적으로, 그것은 너가 stream sockets으로 할 때 처럼 open connection을 유지할 필요가 없기 때문이다. 너는 패킷을 구성하고, IP header를 목적지 정보와함께 그것에 붙이고, 그리고 밖으로 내보낸다. 어떠한 연결도 필요없다. 그것들은 TCP 스택이 이용가능하지 않거나 또는 여기저기에 몇 개의 떨어진 패킷들이 Universe의 끝을 의미하지 않을 때 일반적으로 사용된다. 샘플 프로그램은 : tftp(trivial file transfer protocol, a little brother to FTP), dhcpcd(a DHCP client), multiplayer games, streaming audio, video conferenceing, etc.

"잠깐 기다려! tftp와 dhcpcd는 한 호스트에서 다른 곳으로 이진 프로그램을 보낼 때 사용된다! 만약 너가 그 프로그램이 그것이 도착할 때 작동하도록 기대한다면 데이터는 손실될 수 있다. 이것이 무슨 종류의 흑마법인가?"

음, 나의 사람 친구야, tftp와 비슷한 프로그램들은 UDP 위에서 그들 자신만의 프로토콜을 갖는다. 예를들어, tftp 프로토콜은 보내진 각각의 패킷에 대해서 그 수령자는 "I got it!" ("ACK" packet)라고 말하는 한 packet을 다시 보내야만 한다. 만약 원래 패킷의 보내는 사람이 어떠한 답장도 받지 못한다면, 가령 5초 후에, 그는 그가 ACK를 받을 때 까지 그 패킷을 재전송할 것이다. 신뢰할만한 SOCK_DGRAM 프로그램을 구현할 때 이 인정 절차는 매우 중요하다.

게임들, 오디오, 또는 비디오 같은 신뢰할 수 없는 프로그램들에 대해서, 너는 단순히 떨어진 패킷들을 무시하고 또는 아마도 똑똑하게 그것들에게 보상을 하려고 한다. (Quake 플레이어들은 기술적용어로 그 징후를 알 것이다: accursed lag. "accursed"라는 단어는 이 경우에 어떤 매우 불경한 말을 나타낸다.)

왜 너는 신뢰할 수 없고 밑에 있는 프로토콜을 사용하는가? 두 가지 이유가 있다: 속도와 속도. 발사하고 잊어버리는게 무엇이 안전하게 도착했는지 추적하고 순서대로 유지하는것 보다 더 빠르다. 만약 너가 채팅 메세지를 보낸다면, TCP는 훌륭하다; 만약 너가 월드에 있는 플레이어들에 대해 초당 40개의 위치를 업데이트 하려 한다면, 한 개 또는 두 개가 떨어져 나가도 그것은 많이 중요하지 않다. UDP가 좋은 선택이다.

2.2 Low level Nonsense and Network Theory
내가 프로토콜의 계층에 대해 언급했기 때문에, 네트워크가 정말로 어떻게 작동하는지 말할 시간이고, SOCK_DGRAM 패킷이 어떻게 만들어지에 대한 예제를 보여줄 시간이다. 실제적으로, 너는 이 섹션을 생략할 수 있다. 그러나 이것은 좋은 배경이다.

  Ethernet - IP - UDP -TFTP - Data (Data Encapsulation)

이봐 꼬마, Data Encapsulation에 대해 배울 시간이다! 이것은 매우매우 중요하다. 너무 중요해서 너가 Chico State에서 네트워크 수업을 들으면 너는 그것을 배웠을지도 모른다. 기본적으로 그것은 이것을 말한다: 한 패킷이 태어나고, 그 패킷은 첫 번째 프로토콜에 의해서(가령, TFTP 프로토콜) 한 헤더에서 (결코 footer가 아닌) wrapped된다. ("encapsulated" 된다). 그러고나서 전체 것은 (TFTP 헤더가 포함된) 다시 다음 프로토콜로 캡슐화 된다. (가령 UDP) 그리고나서, 다음(IP)로 캡슐화 되고, 그러고나서 다시 하드웨어(물리적) 계층 (가령 Ethernet)에 있는 마지막 프로토콜로 캡슐화 된다.

다른 컴퓨터가 패킷을 받을 때, 그 하드웨어는 Ethernet header를 벗겨내고, 커널은 IP와 UDP 헤더를 벗겨내고, TFTP 프로그램은 TFTP 헤더를 벗겨내고, 그리고 마침내 그것은 데이터를 갖게 된다.

이제 나는 마침내 악명높은 Layered Network Model(일명 "ISO/OSI")를 말할 수 있다. 이 네트워크 모델은 다른 모델들에 비해 많은 장점을 가진 네트워크 기능성의 한 시스템을 묘사한다. 예를들어, 너는 데이터가 어떻게 물리적으로 전송되는지 신경쓰지 않고 (serial, thin Ethernet, AUI, 무엇이든) 정확히 똑같은 소켓 프로그램들을 쓸 수 있다. 왜냐하면 더 낮은 수준에 있는 프로그램들이 너를 위해 그것을 다룰 테니까. 실제 네트워크 하드웨어와 topology는 소켓 프로그래머에게 명백하다.

더 야단법석 떠들지 않고, 나는 모든 특성을 갖춘 모델의 계층을 보여줄 것이다.
네트워크 수업 시험을 위해 이것을 기억해라:

• Application
• Presentation
• Session
• Transport
• Network
• Data Link
• Physical

Physical Layer는 하드웨어이다. (serial, Ethernet, 등) Application 레이어는 너가 상상하는 만큼 물리적 계층과 먼 것에 대한 것이다. - 그것은 사용자가 네트워크와 상호작용 하는 장소이다.

이제 이 모델은 너무 일반적이여서, 너는 너가 정말 원한다면 자동차 수리 가이드로서 사용할 수 있다. Unix에 좀 더 일관된 계층화된 모델은 이러한 것들이다:

• Application Layer(telnet, ftp, etc.)
• Host-to-Host Transport Layer(TCP, UDP)
• Internet Layer(IP and routing)
• Network Access Layer(Ethernet, wi-fi, or whatever)

이 시점에서, 너는 아마 이러한 계층들이 원래 데이터에 어떻게 일치하는지 볼 수 있다.

간단한 패킷을 구성하는데 얼마나 많은 일들이 있는지 보았는가? 이런! 그리고 너는 "cat"을 사용하여 스스로 페킷 헤더에 쳐야만 한다. 너가 stream socket들을 위해 해야만 하는 모든 것은 data를 send()하는 것이다. 너가 datagram sockets을 위해 해야만 하는 것은 너가 선택하는 방식으로 packet을 캡슐화하고 sendto() 하는 것이다. 커널은 Transport Layer와 Internet Layer를 너를 위해 구성한다. 하드웨어는 Network Access Layer를 한다. 아 현대 기술이여.

그래서 네트워크 이론에 대한 우리의 간단한 급습은 끝낸다. 오 그래, 나는 너에게 routing에 대해서 말하고 싶은 모든 것을 말하려는 것을 잊었었다: 아무것도 아니다! 그게 맞아, 나는 그것에 대해 말하지 않을 것이다. router는 IP header에 대한 패킷을 벗겨내고, 그것의 routing table을 consult한다, blah blah blah. 만약 너가 정말 신경쓰고 싶다면 IP RFC를 참고해라. 만약 너가 그것을 배우지 않는다면, 음 너는 살게 될거야.