tcp 在调用connect失败后要不要重新socket?
来源:互联网 发布:关于新生儿的软件 编辑:程序博客网 时间:2024/04/27 17:51
对TCP套接字调用connect会激发三次握手,如下:
客户端是主动打开连接的一端,会发送第一个SYN分节,然后等待确认,此时连接状态为SYN_SENT,当收到服务端的确认后连接建立,状态变为ESTABLISHED;
服务器是被动打开连接的一端,调用listen导致套接字从CLOSED状态变为LISTEN状态,当收到来自客户端的SYN分节以后状态变为SYN_RCVD,然后发送第二个SYN分节,等待客户端的确认,收到客户端的确认以后连接建立,状态变为ESTABLISHED;
三次握手中的两个SYN分节都会告诉对端本端在同一连接中发送数据的初始序列号,ACK的确认号是本端所期待的下一个序列号,SYN和FIN都占据一个字节的序列号空间;
SYN中携带的TCP选项:
MSS:告知对端本端在本连接中得每个TCP分节中愿意接受的最大数据量,发送端TCP使用接收端的MSS作为所发送分节的最大大小,我们可以通过TCP_MAXSEG套接字选项提取和设置这个TCP选项,TCP_MAXSEG选项原本是只读选项,4.4BSD限制应用进程只能减少其值,不能增加其值。
窗口规模选项:TCP连接任何一端能够通告对端的最大窗口大小是65535,因为在TCP首部中,相应地字段占16位;SO_RCVBUF套接字选项影响这个TCP选项,套接字接收缓冲区中可用空间的大小限定了TCP通告对端的窗口大小;
时间戳选项:这个选项对于高速网络连接是必要的,它可以防止由失而复得的分组可能造成的数据损坏,这个失而复得是指由暂时的路由原因造成的迷途,路由稳定后又正常到达目的地,高速网络中32位的序列号很快就可能循环一轮重新使用,如果不用时间戳选项,失而复得的分组所承载的分节可能与再次使用相同序列号的真正分节发生混淆;
connect(套接字默认阻塞)出错返回的情况:
1. 调用connect时内核发送一个SYN分节,若无响应则等待6s后再次发送一个,仍无响应则等待24s再发送一个,若总共等了75s后仍未收到响应则返回ETIMEDOUT错误;
2. 若对客户的SYN的响应是RST,则表示该服务器主机在我们指定的端口上面没有进程在等待与之连接,例如服务器进程没运行,客户收到RST就马上返回ECONNREFUSED错误;
3. 若客户发出的SYN在中间的某个路由上引发了一个“destination unreachable”(目的不可达)ICMP错误,客户主机内核保存该消息,并按1中所述的时间间隔发送SYN,在某个规定的时间(4.4BSD规定75s)仍未收到响应,则把保存的ICMP错误作为EHOSTUNREACH或ENETUNREACH错误返回给进程。
若connect失败则该套接字不再可用,必须关闭,我们不能对这样的套接字再次调用connect函数。
在每次connect失败后,都必须close当前套接字描述符并重新调用socket。
我们重现一下这些错误:
首先看下以下系统定义:
#defineENETUNREACH51/* Network is unreachable */
#defineETIMEDOUT60/* Operation timed out */
#defineECONNREFUSED61/* Connection refused */
客户端:
连接失败,errno = 60
不运行服务端,直接运行客户端会复现第二种情况,直接打印如下信息:
连接失败,errno = 61
关掉wifi,直接运行会复现第三种情况,直接打印如下信息:
连接失败,errno = 51
这里有个疑问,要是服务端打开屏蔽listen的那行代码会怎么样,再运行,客户端打印:
连接成功
我们服务端没有调用accept代码呀,这是因为调用listen方法后,内核为任何一个给定的监听套接字维护两个队列:未完成连接队列和已完成连接队列如下图所示;当客户SYN到达时,如果队列是满的,TCP就忽略该分节,但不会发送RST;当进程调用accept时,已完成队列的对头项将返回给进程,如果队列是空,则阻塞(套接字默认阻塞);也就是说只要我调用了listen方法后,服务端就打开了三次握手的开关,能够处理来自客户端的SYN分节了,只要三次握手完成,客户端就会connect成功,而跟服务端调用accept没任何关系,accept只是去取已完成连接队列的对头项。
如图为TCP监听套接字的两个队列:
参考:
《UNIX Network ProgrammingVolume 1, Third Edition: TheSockets Networking API》
- tcp 在调用connect失败后要不要重新socket
- tcp 在调用connect失败后要不要重新socket?
- socket关闭后再new,再connect失败的问题
- connect调用失败后需关闭描述符
- udp socket connect一个不存在的地址后调用sendto返回111错误(connect refused)
- 开源库(要不要重新制造轮子)
- TCP socket上的connect
- 在UDP套接字上调用connect与在TCP上调用的区别
- [Socket] Connect失败,显示Connection refused
- qt connect 后,不调用
- tcp协议系列文章(8):connect:在socket上进行连接初始化
- 在存储过程中使用了DML语句要不要调用COMMIT?
- c++ socket调用gethostbyname()失败
- TCP/UDP与connect系统调用
- udp socket 调用connect的作用是什么
- [Linux]关于非阻塞socket调用connect
- java调用tcp socket接口
- 最近在考虑要不要换新博客
- 文章标题
- L2-013. 红色警报 (并查集其他利用)
- 位运算
- 数据结构+算法
- 同一个Activity下的fragment之间的跳转
- tcp 在调用connect失败后要不要重新socket?
- ceshi1
- media指令分析
- js中的sort()方法
- Python学习
- C#中设置Excel单元格格式
- CentOS 7 下配置java web 所需要的环境
- apache 配置文件
- viewpager中去掉滑动,保留点击功能