佛山高端网站制作公司,网络营销平台建设,python如何调用wordpress,移动网站登录入口验证客户端和服务端三次握手和四次挥手时的状态
三次握手
#include sys/types.h
#include sys/socket.h
int listen(int sockfd, int backlog);netstat ntp
//查看连接的状态 将TCP服务端套接字设置为listen状态之后#xff0c;此时服务端是处于L…验证客户端和服务端三次握手和四次挥手时的状态
三次握手
#include sys/types.h
#include sys/socket.h
int listen(int sockfd, int backlog);netstat ntp
//查看连接的状态 将TCP服务端套接字设置为listen状态之后此时服务端是处于LISTEN状态的服务端没有使用accept接口时在收到客户端的连接请求时双方会经历3次握手最终都处于ESTABLISHED状态即连接的建立和accept没有关系三次握手是双方操作系统自动完成的
当listen的第二个参数设为一时能建立全连接的连接数是2操作系统会将没有被上层accept的连接管理起来对它们先描述再组织并且以队列的方式管理这些连接结构三次握手时每次形成的连接本质上就是创建一个连接结构体对象并将其链入到队列当中而accept就是从队列中将连接取走和特定的文件关联起来返回特定的文件描述符listen的第二个参数1表示已经建立好的连接队列的最大长度这个队列叫做全连接队列accept和连接入队还有全连接队列构成了CP模型服务端三次握手完成或者建立连接成功就将连接入队列如果队列满了就无法入队列了就会将连接状态设置为SYN_RECV状态换句话说就是因为全连接队列满了服务端将客户端发送过来的第三次握手应答报文直接丢弃了
如果服务端长时间无法得到应答就会释放掉SYN_RECV状态的连接这种连接叫做半连接半连接也需要进行管理所以也会存在半连接队列节点并不会长时间维持
这样就出现了客户端和服务器连接不一致的问题服务端直接将应答丢弃但是确实是收到了应答所以第二次握手是可靠的知道客户端建立连接成功了并不会发送RST标志位对于客户端建立连接成功了但是发送数据不成功就转而继续开始进行三次握手
大量建立半连接会导致真正地SYN洪水服务器资源有限制不会挂掉但是其他客户端就无法正常的访问了
全连接队列长度不可以太长因为上层处理繁忙时就无法保证将全连接队列获取完而队列长度过长就会导致资源闲置维护还要有成本而且变相地减少了上层空间降低了处理的效率而队列的存在可以保证半连接变成全连接和全连接被上层处理可以并发运行所以一般全连接队列的长度一般要设置为10左右
四次挥手
当客户端关闭连接时服务端的连接会处于CLOSE_WAIT状态由于服务端不关闭连接会维持此状态维持一段时间直到关闭连接时才会将此状态改为LASTACK收到应答后关闭连接
主动关闭连接的一方最终会先处于TIME_WAIT状态(连接没有完全断开)一般维持60-120s的时长这时候就不可以重新绑定端口号因为连接没有完全断开意味着IP和端口号还在被使用并且一个端口号只能绑定一个进程所以重启服务会失败得等待60-120s对于一个服务器不可以立即重启会产生很大的损失所以需要修改此状态进行地址复用
#include sys/types.h /* See NOTES */
#include sys/socket.h
int getsockopt(int sockfd, int level, int optname,void *optval, socklen_t *optlen);
int setsockopt(int sockfd, int level, int optname,const void *optval, socklen_t optlen);//将TIME_WAIT的IP和端口号复用
//第一个参数是要被修改属性的套接字第二个参数一般是SOL_SOCKET表示在套接字层第三个参数表示操作名字如复用IP和端口号第四个参数表示将选项设置为有效
int opt 1;
setsockopt(listensockfd_, SOL_SOCKET, SO_REUSEADDR|SO_REUSEPORT, opt, sizeof(opt));
//这样就可以重新建立好连接了 客户端能够立即重连是因为使用的是系统分配的随机端口号所以重连时的端口号与上一次不一样就不会出现绑定失败的情况
MSL数据报在网络中最多存活的时长
TCP协议规定,主动关闭连接的一方要处于TIME_ WAIT状态,等待两个MSL(maximum segment lifetime)的时间后才能回到CLOSED状态MSL在RFC1122中规定为两分钟,但是各操作系统的实现不同, 在Centos7上默认配置的值是60s可以通过 cat /proc/sys/net/ipv4/tcp_fin_timeout 查看msl的值
1.TIME_WAIT等待两个MSL时间是因为要让历史数据在网络中消散(否则服务器立刻重启, 可能会收到来自上一个进程的迟到的数据, 但是这种数据很可能是错误的)序号一般是随机的防止黑客的恶意攻击和历史保温的影响
2.让断开连接四次挥手具有较好的容错性
最大存在时长不等于最大传送时长还包括了异常的路由阻塞时间一般TIME_WAIT时长为60-120秒如果没有accept可能就会没有TIME_WAIT状态直接关闭
11.3.7流量控制
流量控制不仅保证了可靠性而且提高了效率捎带应答也是保证可靠性并且提高效率
流量控制发送方通过接收到接收方发送过来的报头(16位窗口大小)知道接收方接收缓冲区剩余空间的大小进而调整发送速度
对于第一次发送数据报文时也要保证发送的数据量是合理的因为正式通信交换数据之前要通过进行三次握手来可靠的建立连接这期间是发送了报文的通信双发都可以得知对方接收缓冲区的剩余空间大小也可以携带16位窗口大小
第三次握手的时候其实是可以携带数据的即可以是携带应答
当接收方的接收缓冲区写满了发送发继续发送报文会产生丢包为了大规模的减少这种问题就需要进行流量控制1.发送方会定期的向接收方发送窗口探测(仅仅是一个报头不携带数据所以丢失不会产生大影响)当发送方收到窗口探测应答则说明有空间了或者接收端返回了上次数据报文的应答也可以说明有空间了2.接收方会主动发送窗口更新消息(也是一种报头)
以上两种方式一起使用选择最优的一定程度上提高了效率而且两种方式提高了容错性
如果两种方式是执行了一定次数后还没有成功就会认为网络异常并且关闭连接
TCP窗口大小(接收缓冲区的大小)默认最大就是65535字节但是可以配合TCP首部40字节的选项窗口扩大因子M使用实际的窗口大小就是窗口字段的值左移M位这还与操作系统实际提供多大的缓冲区有关
11.3.8滑动窗口
如果串行的发送数据报文加确认应答确实可以保证可靠性但是效率太低所以除了控制使用串行的方式常规都是使用并行的方式发送一批数据报文后才接受一批确认应答没有收到应答就会使用超时重传机制
为了保证数据的可靠性需要在设置的特殊时间间隔里将大量的发送数据报文管理起来这些数据报文本来就存在于发送缓冲区没必要专门再拷贝一份的方式维护只需要将发送缓冲区进行划分即可
可以简单地划分为三部分从左往右依次为已发送已确认区域已发送未确认区域待发送区域对于已发送已确认的区域是可以被覆盖的已发送未确认区域可以继续发送数据即支持发送一批数据如果没有收到应答就继续维护此数据如果收到了应答就将此数据移动到已发送已确认区域表示此数据已经被清理掉已发送未确认区域就叫做滑动窗口
滑动窗口是发送缓冲区的一部分
滑动窗口的数据是可以直接发送给接收方的这样就可以一次性发送一批数据报文等到接收到应答时在将数据移动到另一个区域不再维护如果没有收到应答就可以进行补发
滑动窗口的大小默认是接收方的16位窗口大小但是还需要考虑到网络的情况
对于发送缓冲区区域的划分可以使用双指针的方式(数组下标)如win_startwin_end来划分成三个区域维护发送缓冲区其实就是修改这些特殊下标缓冲区
收到确认就是应答就是将start右移如果接收方的接收缓冲区变大了就将end右移使得滑动窗口变大这样的过程就像是在滑动换句话说滑动的本质就是指针的右移
网络是不支持发送大块数据的只能分段发送
