套接字层将数据从应用层拷贝到内核缓冲区之后,但是数据什么时候会被内核协议栈发出去?
拷贝也可能会失败,缓冲区可能空间不够了,也就是说缓冲区滞留了很多未发送的数据
套接字层只是提供了内核协议栈与应用层之间交互的系统调用
滑动窗口只是一个控制机制,本身并不包含缓冲区,缓冲区是skb,滑动窗口只是控制了缓冲区的访问,它的缓冲区来自tcp_wmem
或者tcp_rmem
连接的状态机可能会影响滑动窗口的运作,同时滑动窗口的位置还会与epoll类似的事件有关系,什么时候可读可写
滑动窗口中发送的都是一系列的字节号码,每个号码代表了一个字节,这个序号并不是代表包,因为tcp协议是面向字节流的协议,所以滑动窗口是面向字节的,这个发送了一连串的字节号码,并不是表示发送了多个包,而是多个字节,多个字节会组成包,因此并没有违背每次只能允许一个未确认的ack
shutdown与close的区别是舍呢么?
滑动窗口从等停协议优化而来,主要是为了什么?
同时还有一个特征就是累积确认,累积确认的真实含义是指ACK的延迟到达,并不是说发送了很多的字节编号,
才等一个ACK,但是累积确认也有时间限制不能超过500ms
累积确认为了提高信道的利用率
tcp的连接状态机中的状态time_wait
它实际上是主动关闭->被动关闭的通道已经断开,已经是半连接状态,
但是被动关闭->主动关闭方向通道还是可用的,此时被动关闭端还是可以发数据给主动关闭端
tcp的time_wait超时时间是2MSL(Max Segment lifetime),这个值一般是2min,
2MSL 就是4分钟,目的是为了确保主动端发送最后的一个ACK到达被动关闭端,
被动端进入LAST_ACK之后,就是为了等待这个ACK,主动发送端也是为了一旦ACK未收到,
被动端重发FIN+ACK,这段时间主动关闭端也用来处理重传的FIN+ACK
tcp的keep-alive主要是针对客户端机器出故障的情况
tcp的keep-alive不是工作在正常的情况下的发送的,
一旦客户端宕机了没有发送数据了,一开始每隔2小时,发送一个keep-alive包,以后每隔75分钟,再发一次,
如果发了10次,仍然没有响应,最后服务器就主动断开连接.这种情况一般需要应用层来发心跳,因为协议栈的太长了
tcp中的fin_wait_2
等待被动端发送的fin,由于必须要收到被动端的fin+ack,但是ack与fin的到达顺序不同,所以有可能先收到ack,然后才是fin,所以
如果收到的是ack,那么必须再等待fin,也就是fin_wait_2
阅读(774) | 评论(0) | 转发(0) |
