TCP协议详解

参考博客
在可靠的TCP网络通信中,客户端和服务器端通信建立连接的过程可简单表述为三次握手(建立连接的阶段)和四次挥手(释放连接阶段),下图是这两个阶段的一个完整的表述:
在这里插入图片描述
其状态图可以表示为,
在这里插入图片描述
在TCP连接建立的时候,存在一个如下的有限状态机:

在这里插入图片描述
在状态转化图中,其中客户端的状态转移用带箭头的粗实线表示,服务器端的状态转换用带箭头的粗虚线表示。带箭头的细线表示一些不常见的事件,如复位、同时打开、同时关闭等。关于有限状态图可以参考博客http://blog.csdn.net/lycb_gz/article/details/8515062,里面的细节都将的很清楚;如果要深入理解TCP连接建立和释放的过程就需要结合socket编程里的connect(),socket(),bind(),listen(),send(),close()等函数。

从图中看到,三次握手对应的Berkeley Socket 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方试调用,就睡眠等待;客户端调用connect函数之后就发起完成TCP的三次握手,客户端调用connect后,由内核中的TCP协议完成TCP的三次握手,close操作会完成四次挥手。

其中accept发生在三次握手之后。
第一次握手:客户端发送syn包(syn=j)到服务器。
第二次握手:服务器收到syn包,必须确认客户的SYN(ack=j+1),同时自己也发送一个ASK包(ask=k)。
第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1)。
三次握手完成后,客户端和服务器就建立了tcp连接。这时可以调用accept函数获得此连接。

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

  • 建立链接请求:
    1、connect将完成三次握手,accept所监听的fd上,产生读事件,表示有新的链接请求,但此时accept函数并没有调用,在内核中维持了一个完成连接的队列;
  • 关闭链接请求:
    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。

3.close()函数和shutdown()函数的区别:

首先我们来看看close()函数的原型:

 头文件:#include <unistd.h> 
定义函数:int close(int fd);

close 一个套接字的默认行为是把套接字标记为已关闭,然后立即返回到调用进程,该套接字描述符不能再由调用进程使用,也就是说它不能再作为read或write的第一个参数,然而TCP将尝试发送已排队等待发送到对端的任何数据,发送完毕后发生的是正常的TCP连接终止序列。在多进程并发服务器中,父子进程共享着套接字,套接字描述符引用计数记录着共享着的进程个数,当父进程或某一子进程close掉套接字时,描述符引用计数会相应的减一,当引用计数仍大于零时,这个close调用就不会引发TCP的四路握手断连过程。如果是主动调用close()则会发起内核TCP协议的四次挥手,断开连接.

再来看看shutdown()函数的原型:

int shutdown(int sockfd,int howto); //返回成功为0,出错为-1.

该函数的行为依赖于howto的值
1.SHUT_RD:值为0,关闭连接的读这一半。
2.SHUT_WR:值为1,关闭连接的写这一半。
3.SHUT_RDWR:值为2,连接的读和写都关闭。

终止网络连接的通用方法是调用close函数。但使用shutdown能更好的控制断连过程(使用第二个参数)。

当调用SHUT_RD的时候,套接字sockfd的读端将会关闭,不能调用接受数据的函数,这对于协议层没有影响。然和当前在sockfd读端的数据缓冲区的数据都会被舍弃掉,进程将不能对该套接字发起读操作,对TCP套接字调用SHUT_RD将会导致协议层将接收到的数据无声的丢掉!!!如果想要继续接受数据都要重置链接;
当调用SHUT_WR的时候,对于tcp套接字来说,这意味着会在所有数据发送出并得到接受端确认后产生一个FIN包。而此时套接字的状态会由ESTABLISHED变成FIN_WAIT_1,然后对方发送一个 ACK包作为回应,套接字又变成FIN_WAIT_2。如果对方也关闭了连接则对方会发出FIN,我方会回应一个ACK并将套接字置为 TIME_WAIT。

4.如何判断socket连接断开:
非阻塞模式,如果暂时没有数据,返回的值也会是<=0的,如果用阻塞模式的话,返回<=0的值是可以认为socket已经无效了。当使用 select()函数测试一个socket是否可读时,如果select()函数返回值为1,且使用recv()函数读取的数据长度为0 时,就说明该socket已经断开。经过代码试验,如果进程受到一些信号时,例如:EINTR,recv()返回值小于等于0时,这是就需要判断 errno是否等于 EINTR , 如果errno == EINTR 则说明recv函数是由于程序接收到信号后返回的,socket连接还是正常的,不应close掉socket连接。如果write,我觉得还有一些情况需要考虑,那就是写的太快的时候,有可能buffer写满了,errno是EAGAIN,可以根据实际需要,如果errno是EAGAIN的话,再写几次。

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

攻城有术

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值