Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1347642
  • 博文数量: 277
  • 博客积分: 2551
  • 博客等级: 少校
  • 技术积分: 3918
  • 用 户 组: 普通用户
  • 注册时间: 2011-02-21 22:46
文章分类

全部博文(277)

文章存档

2017年(3)

2016年(9)

2015年(65)

2014年(27)

2013年(85)

2012年(61)

2011年(27)

分类: LINUX

2015-05-12 22:54:29

     套接字层将数据从应用层拷贝到内核缓冲区之后,但是数据什么时候会被内核协议栈发出去?
           拷贝也可能会失败,缓冲区可能空间不够了,也就是说缓冲区滞留了很多未发送的数据
     套接字层只是提供了内核协议栈与应用层之间交互的系统调用
     滑动窗口只是一个控制机制,本身并不包含缓冲区,缓冲区是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
     
阅读(718) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~