socket工作原理深入分析

socket原理分析

本篇文章摘自https://www.cnblogs.com/zengzy/p/5107516.html，总结的很好，所以摘过来总结整理一下，如果朋友们还想更加深入的研究网络，推荐大家学习一下tcp/ip协议这本书。受益匪浅！

本节目录

一 iso七层模型
二什么是socket
三如何标识socket实例
四 socket接口

一 iso七层模型

看到这里相信大家对iso七层模型已经有所了解了，如果没有了解，赶紧去恶补一下啦~~

直接上图：

iso七层模型图片

二什么是socket

首先我们python基础部分已经学完了，而socket是我们基础进阶的课程，也就是说，你自己现在完全可以写一些小程序了，但是前面的学习和练习，我们写的代码都是在自己的电脑上运行的，虽然我们学过了模块引入，文件引入import等等，我可以在程序中获取到另一个文件的内容，对吧，但是那么突然有一天，你的朋友和你说："把你电脑上的一个文件通过你自己写的程序发送到我的电脑上"，这时候怎么办？你是不是会想，what？这怎么搞？就在此时，突然灵感来了，我可以通过qq、云盘、微信等发送给他啊，可是人家说了，让你用自己写的程序啊，嗯，这是个问题，此时又来一个灵感，我给他发送文件肯定是通过网络啊，这就产生了网络，对吧，那我怎么让我的程序能够通过网络来联系到我的朋友呢，并且把文件发送给他呢，那么查了一下，发现网络通信通过socket可以搞，但是怎么搞呢？首先，查询结果是对的，socket就是网络通信的工具，任何一门语言都有socket，他不是任何一个语言的专有名词，而是大家通过自己的程序与其他电脑进行网络通信的时候都用它。知道为什么要学习socket了吧~~朋友们~~而你使用自己的电脑和别人的电脑进行联系并发送消息或者文件等操作就叫做网络通信，而网络通信需要使用socket作为工具。看下图(图一)

图一:各协议所处层次

当然，这样做固然是可以的，但是，当我们使用不同的协议进行通信时就得使用不同的接口，还得处理不同协议的各种细节，这就增加了开发的难度，软件也不易于扩展。于是UNIX BSD就发明了socket这种东西，socket屏蔽了各个协议的通信细节，使得程序员无需关注协议本身，直接使用socket提供的接口来进行互联的不同主机间的进程的通信。这就好比操作系统给我们提供了使用底层硬件功能的系统调用，通过系统调用我们可以方便的使用磁盘（文件操作），使用内存，而无需自己去进行磁盘读写，内存管理。socket其实也是一样的东西，就是提供了tcp/ip协议的抽象，对外提供了一套接口，同过这个接口就可以统一、方便的使用tcp/ip协议的功能了。看下图(图二)

图二:socket在内的各层

那么，在BSD UNIX又是如何实现这层抽象的呢？我们知道unix中万物皆文件，没错，bsd在实现上把socket设计成一种文件，然后通过虚拟文件系统的操作接口就可以访问socket，而访问socket时会调用相应的驱动程序，从而也就是使用底层协议进行通信。（vsf也就是unix提供给我们的面向对象编程，如果底层设备是磁盘，就对磁盘读写，如果底层设备是socket就使用底层协议在网中进行通信，而对外的接口都是一致的）。下面再看一下socket的结构是怎样的（图片来源于《tcp/ip协议详解卷二》章节一，1.8描述符），注意：这里的socket是一个实例化之后的socket，也就是说是一个具体的通信过程中的socket，不是指抽象的socket结构，下文还会进行解释。看下图(图三)

图三 udp socket实例的结构

很明显，unix把socket设计成文件，通过描述符我们可以定位到具体的file结构体，file结构体中有个f_type属性，标识了文件的类型，如图，DTYPE_VNODE表示普通的文件DTYPE_SOCKET表示socket，当然还有其他的类型，比如管道、设备等，这里我们只关心socket类型。如果是socket类型，那么f_ops域指向的就是相应的socket类型的驱动，而f_data域指向了具体的socket结构体，socket结构体关键域有so_type,so_pcb。so_type常见的值有：

SOCK_STREAM 提供有序的、可靠的、双向的和基于连接的字节流服务，当使用Internet地址族时使用TCP。
SOCK_DGRAM 支持无连接的、不可靠的和使用固定大小（通常很小）缓冲区的数据报服务，当使用Internet地址族使用UDP。
SOCK_RAW 原始套接字，允许对底层协议如IP或ICMP进行直接访问，可以用于自定义协议的开发。

so_pcb表示socket控制块，其又指向一个结构体，该结构体包含了当前主机的ip地址(inp_laddr)，当前主机进程的端口号(inp_lport)，发送端主机的ip地址(inp_faddr)，发送端主体进程的端口号(inp_fport)。so_pcb是socket类型的关键结构，不亚于进程控制块之于进程，在进程中，一个pcb可以表示一个进程，描述了进程的所有信息，每个进程有唯一的进程编号，该编号就对应pcb；socket也同时是这样，每个socket有一个so_pcb，描述了该socket的所有信息，而每个socket有一个编号，这个编号就是socket描述符。说到这里，我们发现，socket确实和进程很像，就像我们把具体的进程看成是程序的一个实例，同样我们也可以把具体的socket看成是网络通信的一个实例。

三如何标识socket实例

我们知道具体的一个文件可以用一个路径来表示，比如/home/zzy/src_code/client.c，那么具体的socket实例我们该如何表示呢，其实就是使用上面提到的so_pcb的那几个关键属性，也就是使用so_type+ip地址+端口号。如果我们使用so_type+ip地址+端口号实例一个socket，那么互联网上的其他主机就可以与该socket实例进行通信了。所以下面我们看一下socket如何进行实例化，看看socket给我们提供了哪些接口，而我们又该如何组织这些接口。

四 socket接口

下面我们看一下socket提供的这些接口(实例方法)都是做什么的，里面的参数又是什么意思

4.1 socket实例接口

int socket(int protofamily, int so_type, int protocol);

protofamily 指协议族，常见的值有：

AF_INET，指定so_pcb中的地址要采用ipv4地址类型

AF_INET6，指定so_pcb中的地址要采用ipv6的地址类型

AF_LOCAL/AF_UNIX，指定so_pcb中的地址要使用绝对路径名

当然也还有其他的协议族，用到再学习了
so_type 指定socket的类型，也就是上面讲到的so_type字段，比较常用的类型有：

SOCK_STREAM:对应tcp

SOCK_DGRAM：对应udp

SOCK_RAW：自定义协议或者直接对应ip层
protocol 指定具体的协议，也就是指定本次通信能接受的数据包的类型和发送数据包的类型，常见的值有：

IPPROTO_TCP，TCP协议

IPPROTO_UDP，UPD协议

0，如果指定为0，表示由内核根据so_type指定默认的通信协议

举例：对于socket(AF_INET, SOCK_RAW, IPPROTO_IP),其原型为int socket (int domain, int type, int protocol)

参数protocol用来指明所要接收的协议包，如果是象IPPROTO_TCP(6)这种非0、非255的协议，当操作系统内核碰到ip头中protocol域和创建socket所使用参数protocol相同的IP包，就会交给这个raw socket来处理，因此，一般来说，要想接收什么样的数据包，就应该在参数protocol里来指定相应的协议。当内核向此raw socket交付数据包的时候，是包括整个IP头的，并且已经是重组好的IP包。
如果protocol是IPPROTO_RAW(255)，这时候，这个socket只能用来发送IP包，而不能接收任何的数据。发送的数据需要自己填充IP包头，并且自己计算校验和。
对于protocol为0（IPPROTO_IP)的raw socket。用于接收任何的IP数据包。其中的校验和和协议分析由程序自己完成。

这是include/linux/in.h里对各类型的IPPROTO的定义: /* Standard well-defined IP protocols. */ enum { IPPROTO_IP = 0, /* Dummy protocol for TCP */ IPPROTO_ICMP = 1, /* Internet Control Message Protocol */ IPPROTO_IGMP = 2, /* Internet Group Management Protocol */ IPPROTO_IPIP = 4, /* IPIP tunnels (older KA9Q tunnels use 94) */ IPPROTO_TCP = 6, /* Transmission Control Protocol */ IPPROTO_EGP = 8, /* Exterior Gateway Protocol */ IPPROTO_PUP = 12, /* PUP protocol */ IPPROTO_UDP = 17, /* User Datagram Protocol */ IPPROTO_IDP = 22, /* XNS IDP protocol */ IPPROTO_DCCP = 33, /* Datagram Congestion Control Protocol */ IPPROTO_RSVP = 46, /* RSVP protocol */ IPPROTO_GRE = 47, /* Cisco GRE tunnels (rfc 1701,1702) */ IPPROTO_IPV6 = 41, /* IPv6-in-IPv4 tunnelling */ IPPROTO_ESP = 50, /* Encapsulation Security Payload protocol */ IPPROTO_AH = 51, /* Authentication Header protocol */ IPPROTO_BEETPH = 94, /* IP option pseudo header for BEET */ IPPROTO_PIM = 103, /* Protocol Independent Multicast */ IPPROTO_COMP = 108, /* Compression Header protocol */ IPPROTO_SCTP = 132, /* Stream Control Transport Protocol */ IPPROTO_UDPLITE = 136, /* UDP-Lite (RFC 3828) */ IPPROTO_RAW = 255, /* Raw IP packets */ IPPROTO_MAX };

再具体的参数解析可以参考这篇文章socket函数的domain、type、protocol解析

这里解释一下图三，图三其实是使用AF_INET,SOCK_DGRAM,IPPRTO_UDP实例化之后的一个具体的socket。

那为什么要通过这三个参数来生成一个socket描述符？

答案就是通过这三个参数来确定一组固定的操作。我们说过抽象的socket对外提供了一个统一、方便的接口来进行网络通信，但对内核来说，每一个接口背后都是及其复杂的，同一个接口对应了不同协议，而内核有不同的实现，幸运的是，如果确定了这三个参数，那么相应的接口的映射也就确定了。在实现上，BSD就把socket分类描述，每一个类别都有进行通信的详细操作，分类见下图。而对socket的分类，就好比对unix设备的分类，我们对设备write和read时，底层的驱动是有各个设备自己提供的，而socket也一样，当我们指定不同的so_type时，底层提供的通信细节也由相应的类别提供。看图四

图四 socket层次图

4.2 bind接口

int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen);

bind函数就是给图三种so_pcb结构中的地址赋值的接口

sockfd 是调用socket()函数创建的socket描述符
addr 是具体的地址
addrlen 表示addr的长度

举struct sockaddr其实是void的typedef，其常见的结构如下图（图片来源传智播客邢文鹏linux系统编程的笔记），这也是为什么需要addrlen参数的原因，不同的地址类型，其地址长度不一样：

图五地址结构图

4.3 connect接口

int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen);

这三个参数和bind的三个参数类型一直，只不过此处strcut sockaddr表示对端公开的地址。三个参数都是传入参数。connect顾名思义就是拿来建立连接的函数，只有像tcp这样面向连接、提供可靠服务的协议才需要建立连接

4.4 listen接口

int listen(int sockfd, int backlog)

告知内核在sockfd这个描述符上监听是否有连接到来，并设置同时能完成的最大连接数为backlog。3.6节还会继续解释这个参数。当调用listen后，内核就会建立两个队列，一个SYN队列，表示接受到请求，但未完成三次握手的连接；另一个是ACCEPT队列，表示已经完成了三次握手的队列

sockfd 是调用socket()函数创建的socket描述符
backlog 已经完成三次握手而等待accept的连接数

关于backlog , man listen的描述如下：

The behavior of the backlog argument on TCP sockets changed with Linux 2.2. Now it specifies the queue length for completely established sockets waiting to be accepted, instead of the number of incomplete connection requests. The maximum length of the queue for incomplete sockets can be set using /proc/sys/net/ipv4/tcp_max_syn_backlog. When syncookies are enabled there is no logical maximum length and this setting is ignored. See tcp(7) for more information.翻译：TCP套接字上的积压参数的行为随着Linux 2.2而改变。现在，它指定等待被接受的完全建立的套接字的队列长度，而不是不完整连接请求的数量。不完整套接字队列的最大长度可以使用/PRO/sys／NET/IPv4/TCPPMAX Syth-ByLoSQL来设置。当启用同步功能时，没有逻辑最大长度，并且忽略该设置。有关更多信息，请参见TCP（7）。
If the backlog argument is greater than the value in /proc/sys/net/core/somaxconn, then it is silently truncated to that value; the default value in this file is 128. In kernels before 2.4.25, this limit was a hard coded value, SOMAXCONN, with the value 128.如果backlog参数大于/proc/sys/net/core/somaxconn中的值，那么它将被悄悄地截断为该值；该文件中的默认值为128。在2.4.25之前的内核中，这个限制是一个硬编码的值，SOMAXCONN，值为128。

4.5 accept接口

int accept(int listen_sockfd, struct sockaddr *addr, socklen_t *addrlen)

这三个参数与bind的三个参数含义一致，不过，此处的后两个参数是传出参数。在使用listen函数告知内核监听的描述符后，内核就会建立两个队列，一个SYN队列，表示接受到请求，但未完成三次握手的连接；另一个是ACCEPT队列，表示已经完成了三次握手的队列。而accept函数就是从ACCEPT队列中拿一个连接，并生成一个新的描述符，新的描述符所指向的结构体so_pcb中的请求端ip地址、请求端端口将被初始化。

从上面可以知道，accpet的返回值是一个新的描述符，我们姑且称之为new_sockfd。那么new_sockfd和listen_sockfd有和不同呢？不同之处就在于listen_sockfd所指向的结构体so_pcb中的请求端ip地址、请求端端口没有被初始化，而new_sockfd的这两个属性被初始化了。

4.6 listen、connect、accept流程及原理

以AF_INET,SOCK_STREAM,IPPROTO_TCP三个参数实例化的socket为例，通过一个副图来讲解这三个函数的工作流程及粗浅原理，看图六

图六 listen、accept、connect流程及原理图

服务器端在调用listen之后，内核会建立两个队列，SYN队列和ACCEPT队列，其中ACCPET队列的长度由backlog指定。
服务器端在调用accpet之后，将阻塞，等待ACCPT队列有元素。
客户端在调用connect之后，将开始发起SYN请求，请求与服务器建立连接，此时称为第一次握手。
服务器端在接受到SYN请求之后，把请求方放入SYN队列中，并给客户端回复一个确认帧ACK，此帧还会携带一个请求与客户端建立连接的请求标志，也就是SYN，这称为第二次握手
客户端收到SYN+ACK帧后，connect返回，并发送确认建立连接帧ACK给服务器端。这称为第三次握手
服务器端收到ACK帧后，会把请求方从SYN队列中移出，放至ACCEPT队列中，而accept函数也等到了自己的资源，从阻塞中唤醒，从ACCEPT队列中取出请求方，重新建立一个新的sockfd，并返回。

这就是listen,accept,connect这三个函数的工作流程及原理。从这个过程可以看到，在connect函数中发生了两次握手。

关于backlog , man listen的描述如下：

4.7 tcp的send接口

没有摘录源码进行分析(这个靠你自己啦)，这里之说一下大致原理

send函数只负责将数据提交给协议层。当调用该函数时，send先比较待发送数据的长度len和套接字s的发送缓冲区的长度，如果len大于s的发送缓冲区的长度，该函数返回SOCKET_ERROR；如果len小于或者等于s的发送缓冲区的长度，那么send先检查协议是否正在发送s的发送缓冲中的数据；如果是就等待协议把数据发送完，如果协议还没有开始发送s的发送缓冲中的数据或者s的发送缓冲中没有数据，那么send就比较s的发送缓冲区的剩余空间和len；如果len大于剩余空间大小，send就一直等待协议把s的发送缓冲中的数据发送完，如果len小于剩余空间大小，send就仅仅把buf中的数据copy到剩余空间里（注意并不是send把s的发送缓冲中的数据传到连接的另一端的，而是协议传的，send仅仅是把buf中的数据copy到s的发送缓冲区的剩余空间里）。如果send函数copy数据成功，就返回实际copy的字节数，如果send在copy数据时出现错误，那么send就返回SOCKET_ERROR；如果send在等待协议传送数据时网络断开的话，那么send函数也返回SOCKET_ERROR。要注意send函数把buf中的数据成功copy到s的发送缓冲的剩余空间里后它就返回了，但是此时这些数据并不一定马上被传到连接的另一端。如果协议在后续的传送过程中出现网络错误的话，那么下一个Socket函数就会返回SOCKET_ERROR。（每一个除send外的Socket函数在执行的最开始总要先等待套接字的发送缓冲中的数据被协议传送完毕才能继续，如果在等待时出现网络错误，那么该Socket函数就返回SOCKET_ERROR）

4.8 tcp的recv接口

没有摘录源码进行分析(这个靠你自己啦)，这里之说一下大致原理

recv先检查套接字s的接收缓冲区，如果s接收缓冲区中没有数据或者协议正在接收数据，那么recv就一直等待，直到协议把数据接收完毕。当协议把数据接收完毕，recv函数就把s的接收缓冲中的数据copy到buf中（注意协议接收到的数据可能大于buf的长度，所以在这种情况下要调用几次recv函数才能把s的接收缓冲中的数据copy完。recv函数仅仅是copy数据，真正的接收数据是协议来完成的），recv函数返回其实际copy的字节数。如果recv在copy时出错，那么它返回SOCKET_ERROR；如果recv函数在等待协议接收数据时网络中断了，那么它返回0 。对方优雅的关闭socket并不影响本地recv的正常接收数据；如果协议缓冲区内没有数据，recv返回0，指示对方关闭；如果协议缓冲区有数据，则返回对应数据(可能需要多次recv)，在最后一次recv时，返回0，指示对方关闭。

4.9 send和recv的缓存区设置

既然提到了send和recv的大致原理，那么担心大家会问如何设置缓冲区大小啊，那么在这里做一下解释

通过setsockopt设置SO_SNDBUF、SO_RCVBUF这连个默认缓冲区的值，再用getsockopt获取设置的值。

今天有点累了，等我整理一下linux和windows下socket缓冲区配置文件的代码，再发给大家吧~~谢谢~~

回到顶部