C语言开发总结（九）

Socket send函数和recv函数协议角度解释

1.send 函数

int send( SOCKET s, const char FAR *buf, int len, int flags );  

    不论是客户还是服务器应用程序都用send函数来向TCP连接的另一端发送数据。客户程序一般用send函数向服务器发送请求，而服务器则通常用send函数来向客户程序发送应答。

    该函数的第一个参数指定发送端套接字描述符；

    第二个参数指明一个存放应用程序要发送数据的缓冲区；

    第三个参数指明实际要发送的数据的字节数；

    第四个参数一般置0。 

    这里只描述同步Socket的send函数的执行流程。当调用该函数时，

   （1）send先比较待发送数据的长度len和套接字s的发送缓冲的长度， 如果len大于s的发送缓冲区的长度，该函数返回SOCKET_ERROR；

   （2）如果len小于或者等于s的发送缓冲区的长度，那么send先检查协议是否正在发送s的发送缓冲中的数据，如果是就等待协议把数据发送完，如果协议还没有开始发送s的发送缓冲中的数据或者s的发送缓冲中没有数据，那么send就比较s的发送缓冲区的剩余空间和len

   （3）如果len大于剩余空间大小，send就一直等待协议把s的发送缓冲中的数据发送完

   （4）如果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）

注意：在Unix系统下，如果send在等待协议传送数据时网络断开的话，调用send的进程会接收到一个SIGPIPE信号，进程对该信号的默认处理是进程终止。

通过测试发现，异步socket的send函数在网络刚刚断开时还能发送返回相应的字节数，同时使用select检测也是可写的，但是过几秒钟之后，再send就会出错了，返回-1。select也不能检测出可写了。

 

2. recv函数

int recv( SOCKET s, char FAR *buf, int len, int flags);   

    不论是客户还是服务器应用程序都用recv函数从TCP连接的另一端接收数据。该函数的第一个参数指定接收端套接字描述符；

    第二个参数指明一个缓冲区，该缓冲区用来存放recv函数接收到的数据；

    第三个参数指明buf的长度；

    第四个参数一般置0。

    这里只描述同步Socket的recv函数的执行流程。当应用程序调用recv函数时，

    （1）recv先等待s的发送缓冲中的数据被协议传送完毕，如果协议在传送s的发送缓冲中的数据时出现网络错误，那么recv函数返回SOCKET_ERROR，

    （2）如果s的发送缓冲中没有数据或者数据被协议成功发送完毕后，recv先检查套接字s的接收缓冲区，如果s接收缓冲区中没有数据或者协议正在接收数据，那么recv就一直等待，直到协议把数据接收完毕。当协议把数据接收完毕，recv函数就把s的接收缓冲中的数据copy到buf中（注意协议接收到的数据可能大于buf的长度，所以 在这种情况下要调用几次recv函数才能把s的接收缓冲中的数据copy完。recv函数仅仅是copy数据，真正的接收数据是协议来完成的），

    recv函数返回其实际copy的字节数。如果recv在copy时出错，那么它返回SOCKET_ERROR；如果recv函数在等待协议接收数据时网络中断了，那么它返回0。

注意：在Unix系统下，如果recv函数在等待协议接收数据时网络断开了，那么调用recv的进程会接收到一个SIGPIPE信号，进程对该信号的默认处理是进程终止。

socket连接和TCP连接的关系

我们在传输数据时，可以只使用（传输层）TCP/IP协议，但是那样的话，如果没有应用层，便无法识别数据内容，如果想要使传输的数据有意义，则必须使用到应用层协议，应用层协议有很多，比如HTTP、FTP、TELNET等，也可以自己定义应用层协议。WEB使用HTTP协议作应用层协议，以封装HTTP文本信息，然后使用TCP/IP做传输层协议将它发到网络上。

1)Socket是一个针对TCP和UDP编程的接口，你可以借助它建立TCP连接等等。而TCP和UDP协议属于传输层 。

  而http是个应用层的协议，它实际上也建立在TCP协议之上。 

 (HTTP是轿车，提供了封装或者显示数据的具体形式；Socket是发动机，提供了网络通信的能力。)

2）Socket是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口（API），通过Socket，我们才能使用TCP/IP协议。Socket的出现只是使得程序员更方便地使用TCP/IP协议栈而已，是对TCP/IP协议的抽象，从而形成了我们知道的一些最基本的函数接口。

SOCKET API和TCP STATE的对应关系__三次握手(listen,accept,connect)__四次挥手close及TCP延迟确认(调用一次setsockopt函数，设置TCP_QUICKACK)__长连接API小心“窜包”问题  

在我们学习网络基础时，传输层的协议有TCP和UDP；

在Linux网络编程中，我们使用socket API，实现网络通信。

那么:

        socket API 和 TCP 协议中各个状态是如何对应的呢？我们可以通过下图来看:

          

在socket系统调用中，如何完成三次握手和四次挥手:

        SOCK_DGRAM,即UDP中的connect操作知识在内核中注册对方机器的IP和PORT信息，并没有建立链接的过程，即没有发包，close也不发包）。

       而SOCK_STREAM对应如下:

        connect会完成TCP的三次握手，客户端调用connect后，由内核中的TCP协议完成TCP的三次握手；

        close操作会完成四次挥手。

 

三次握手对应的Berkeley Socket API：

          从图中，可以看出和连接建立相关的API有：connect, listen, accept   3个，connect用在客户端，另外2个用在服务端。

          对于TCP/IP protocol stack来说，TCP层的tcp_in&tcp_out也参与这个过程。我们这里只讨论这3个应用层的API干了什么事情。

         （1） connect

                     发送了一个SYN，收到Server的SYN+ACK后，代表连接完成。发送最后一个ACK是protocol stack,tcp_out完成的。

         （2）listen

                    在server这端，准备了一个未完成的连接队列，保存只收到SYN_C的socket结构；

                    还准备了已完成的连接队列，即保存了收到了最后一个ACK的socket结构。

        （3）accept

                   应用进程调用accept的时候，就是去检查上面说的已完成的连接队列，如果队列里有连接，就返回这个连接；

                   如果没有，即空的，blocking方试调用，就睡眠等待；

                                                   nonblocking方式调用，就直接返回，一般一"EWOULDBLOCK“ errno告诉调用者，连接队列是空的。 

 注意：

        在上面的socket API和TCP STATE的对应关系中，TCP协议中，客户端收到Server响应时，可能会有会延迟确认。

        即客户端收到数据后，会阻塞给Server端确认。

        可以在每次收到数据后:

               调用setsockopt(fd, IPPROTO_TCP, TCP_QUICKACK, (int[]){1}, sizeof(int));  快速给Server端确认。

               

我们如何判断有一个建立链接请求或一个关闭链接请求：

      建立链接请求:

1、connect将完成三次握手，accept所监听的fd上，产生读事件，表示有新的链接请求；           

关闭链接请求：

1、close将完成四次挥手，如果有一方关闭sockfd，对方将感知到有读事件，

      如果read读取数据时，返回0，即读取到0个数据，表示有断开链接请求。(在操作系统中已经这么定义) 

关闭链接过程中的TCP状态和SOCKET处理，及可能出现的问题:

1. TIME_WAIT

 TIME_WAIT 是主动关闭 TCP 连接的那一方出现的状态，系统会在 TIME_WAIT 状态下等待 2MSL（maximum segment lifetime  ）后才能释放连接（端口）。通常约合 4 分钟以内。

TIME_WAIT 状态等待 2MSL 的意义：

          1、确保连接可靠地关闭； 即防止最后一个ACK丢失。

          2、避免产生套接字混淆（同一个端口对应多个套接字）。

 为什么说可以用来避免套接字混淆呢？

        一方close发送了关闭链接请求，对方的应答迟迟到不了(例如网络原因)，导致TIME_WAIT超时，此时这个端口又可用了，我们在这个端口上又建立了另外一个socket链接。 如果此时对方的应答到了，怎么处理呢？其实这个在TCP层已经处理了，由于有TCP序列号，所以内核TCP层，就会将包丢掉，并给对方发包，让对方将sockfd关闭。所以应用层是没有关系的。即我们用socket API编写程序，就不用处理。

注意::

         TIME_WAIT是指操作系统的定时器会等2MSL，而主动关闭sockfd的一方，并不会阻塞。（即应用程序在close时，并不会阻塞）。

         当主动方关闭sockfd后，对方可能不知道这个事件。那么当对方(被动方)写数据，即send时，将会产生错误，即errno为: ECONNRESET。

 服务器产生大量 TIME_WAIT 的原因：(一般我们不这样开发Server，但是web服务器等这种多客户端的Server，是需要在完成一次请求后，主动关闭连接的，否则可能因为句柄不够用，而造成无法提供服务。)

  服务器存在大量的主动关闭操作，需关注程序何时会执行主动关闭（如批量清理长期空闲的套接字等操作）。

  一般我们自己写的服务器进行主动断开连接的不多，除非做了空闲超时之类的管理。(TCP短链接是指，客户端发送请求给服务器，客户端收到服务器端的响应后，关闭链接)。

2. CLOSE_WAIT

 CLOSE_WAIT 是被动关闭 TCP 连接时产生的，

如果收到另一端关闭连接的请求后，本地(Server端)不关闭相应套接字就会导致本地套接字进入这一状态。

(如果对方关闭了，没有收到关闭链接请求，就是下面的不正常情况)

按TCP状态机，我方收到FIN，则由TCP实现发送ACK，因此进入CLOSE_WAIT状态。但如果我方不执行close()，就不能由CLOSE_WAIT迁移到LAST_ACK，则系统中会存在很多CLOSE_WAIT状态的连接。

如果存在大量的 CLOSE_WAIT，则说明客户端并发量大，且服务器未能正常感知客户端的退出，也并未及时 close 这些套接字。(如果不及时处理，将会出现没有可用的socket描述符的问题，原因是sockfd耗尽)。

 

正常情况下::  

        一方关闭sockfd，另外一方将会有读事件产生， 当recv数据时，如果返回值为0，表示对端已经关闭。此时我们应该调用close，将对应的sockfd也关闭掉。

不正常情况下:: 

        一方关闭sockfd，另外一方并不知道，(比如在close时，自己断网了，对方就收不到发送的数据包)。此时，如果另外一方在对应的sockfd上写send或读recv数据。

recv时，将会返回0，表示链接已经断开。

send时， 将会产生错误，errno为ECONNRESET。

长连接API小心“串包”问题：

有时候，我们以API的方式为客户提供服务，如果此时你提供的API采用TCP长连接，而且还使用了TCP接收超时机制（API一般都会提供设置超时的接口，例如通过setsockopt设置SO_RCVTIMEO或这select），那你可能需要小心下面这种情况（这里姑且称之为“窜包”,应用程序没有将应答包与请求包正确对应起来）：
      如果某一笔以TCP接收的请求超时（例如设置为3秒）返回客户，此时客户继续使用该链接发送第二个请求，此时后者就有可能收到前一笔请求的应答（前一笔的应答在3秒后才到达），倘若错误的将此应答当做后者的应答处理，那就可能会导致严重的问题。如果网络不稳定，或者后台处理较慢，超时严重，其中一笔请求应答窜包了，很可能导致后续多个请求应答窜包。例如网上常见的抽奖活动，第一个用户中了一个iPad，而第二个用户在后台中仅为一个虚拟物品，若此时出现窜包，那第二个用户也会被提示中了iPad。

 

这个问题，初看起来最简单的解决办法就是：一旦发现有请求超时，就断开并重新建立连接，但这种方案理论上是不严谨的，考虑下面这种情况：
        1、应答超时的原因是因为应答包在网络中游荡（例如某个路由器崩溃等原因，这类在网络中游荡的包，俗称迷途的分组）；
        2、API在检测到超时后，断开并重新建立的连接的IP和Port与原有连接相同（新连接为被断开连接的化身）；
        3、在新连接建立后，立即发送了一个新的请求，但随后那个迷途的应答包又找到了回家的路，重新到达，此时新连接很有可能将这个不属于自己的包，当做第二个请求的应答（该包的TCP Sequence恰好是新连接期望的TCP Sequence，这种情况是可能的，但是基本不可能发生）。
        注：正常情况下，TCP通过维持TIME_WAIT状态2MSL时间，以避免因化身可能带来的问题。但是在实际应用中，我们可以通过调整系统参数，或者利用SO_LINGER选项使得close一个连接时，直接到CLOSE状态，跳过TIME_WAIT状态，又或者利用了端口重用，这样就可能会出现化身。在实际应用中，上面这种情况基本不会发生，但是从理论上来说，是可能的。

 再仔细分析，就会发现这个问题表面上看是因为“窜包”导致，但本质原因是程序在应用层没有对协议包效验。例如另外一种情况：A、B两个客户端与Server端同时建立了两个连接，如果此时Server端有BUG，错将A的应答，发到B连接上，此时如果没有效验，那同样会出现A请求收到B应答的情况。所以这个问题解决之道就是：在应用层使用类似序列号这类验证机制，确保请求与应答的一一对应。

 

参考文章：

http://pananq.com/index.php/page/9/