计算机网络杂谈

// 网络专业名词
MTU:
  最大传输单元 46～1500 只包含数据(IP数据报)
    不包括帧的首尾部
  不同类型的网络其数据链路层大多有一个数据传输
    上限IP层传来的数据超过这个就要IP分片，这
    个就叫MTU
  同一网络两台主机通信，该网络的MTU非常重要，因
    为这就是两者通信的MTU
  如果两台通信主机之间要经过多个网络，每个网络的
    链路层可能有不同的MTU，此时重要就是这些经过
    网络的最小MTU，称为路径MTU
  A到B的路由可能与B到A的路由不同，因此MTU在不同
    方向不一定是一致的
  大多数的的系统不支持路径MTU发现功能，但可以很
    容易地修改traceroute程序来确定路径MTU:
    发送分组，并设置”不分片“标志比特。一个一个
    尝试，第一个分组长度正好与出口MTU相等，每次
    收到ICMP”不能分片“差错报文就减小分组长度继
    续尝试，怎们减小？正如RFC1191声明，MTU值
    个数是有限的，我们可以查表
MSS:最大报文段长度(TCP报文段长度-TCP首部长度)
    TCP首部最初规定的唯一选项
    MSS与接收窗口值没有关系，与网络路径有关系
      由于IP数据报经过的网络路径是动态变化的
      在这条路径上不需要分片的MSS，走另外一条
      路径可能就要分片
    MSS的取值原则是尽可能大，但是不能让IP分片，
      这很难做到，因为中间某个路由器很差可能超
      过预期要分片
    在刚开始建立连接时双方在TCP首部选项填写自己
      的MSS(双方可不同)，以后就按照这个数值传送
      数据
    默认MSS=536 加20TCP首部 = TCP报文段默认
      长度556
MSL:最长报文段寿命(Maximum Segment Life \
      Time)，工程建议2分钟，但是不同的TCP实
      现可选择更小的
TCP报文段:报文(数据)+首部
UDP用户数据报:报文(数据)+首部
IP数据报:报文(数据)+首部
分组:运输层传送的协议数据单元叫报文段，网络层传
      送的协议数据单元叫IP数据报，一般都简称分
      组(此时我们强调的数据+对应首部，而不管它
      是来自传输层的还是网络层)
帧:数据链路层 首部+数据


// 网络工具
traceroute
netstat


// 数据链路层理论
MAC地址在该层
// 以太网的MAC帧格式
目的地址(6)+源地址(6)+类型(2)+数据(46~1500)
  +FCS(4)
类型:上层协议类型0x800表示IP数据报
数据:
  当数据少于46时，则填充，上层IP数据报是知道有
    效数据的长度的，会自动抛弃无用数据
  帧传输的最大长度就是MTU，即MTU(46~1500)
FCS:CRC的校验
// 网络层理论


// IP理论
首部:20+40(选项) —-4bit最大15(15*4=60)
总长度:
  首部+数据 16bit 最大65535字节
  IP标准规定 所有主机和路由器必须能够处理的
    IP数据报总长度不得小于576字节
  当IP数据报总长度超过数据链路层的MTU就必须
    分片，此时首部中的总长度字段是每个分片后
    子IP数据报的总长度(首部+数据)
首部检验和:
  16bit 只检验首部 因为数据部分已经让TCP和
    UDP自己的检验和检验，并且每经过一个路由器
    都要重新计算这个检验和(因为生存时间，标志，
    片便宜都可能发生变化)，因为比较频繁，所以
    搞简单点，只计算首部，并且不用复杂的CRC，
    用简单反码，在接收路由器，再将各个参与运算
    的位与这个反码运算，如果为0，则表示没出错
    保留
    TCP和UDP为什么检验和还算数据并且用复杂的
      检验算法，因为只要在接收断最后验证一次
源IP:32bit
目的IP:32bit
// 运输层理论
TCP不提供广播或多播的服务
TCP和UDP 首部格式都有 源端口和目的端口
熟知端口号:0~1023
等级端口好:1024~49151 服务器用
客户端使用的端口号:
  49152~65535 客户端临时用，通信结束后
    端口号就不复存在


// ICMP
如果接收方UDP发现收到的UDP用户数据报中的端口
  号不正确，则丢弃该报文并由ICMP发送"端口不
  可达"差错报文给发送方
traceroute发送的UDP用户数据报是非法端口时
  ICMP确实就返回"端口不可达"差错报文


// UDP理论
UDP面向报文（应用数据），而TCP是面向字节流的
  应用程序交下来的报文在添加UDP首部后给IP层
  UDP对交下来的数据既不合并也不拆分
  如果实在太大IP层会分片
应用程序必须选择合适大小的报文(数据)，否则要么
  IP分片，要么IP效率太低
UDP用户数据报:包括报文+首部
UDP支持一对一，一对多，多对多
UDP首部(8)
  源端口(2)+目的端口(2)+长度(2:数据+首部)+ \
    检验和(2)
检验和:
  首部+数据+伪首部
    伪首部(12):源IP(4)+目的IP(4)+0(1)
      +17(1:协议号)+UDP长度(2:数据+首部
      ，即UDP首部中的长度字段)
  UDP检验和把UDP用户数据报的首部和数据(报文)一起
    都检验，而IP数据报的检验和只检验IP数据报首部


// TCP理论
面向连接
全双工
面向字节流
不提供广播和多播的服务
TCP应用程序发多长的报文(数据)给TCP的缓存并不关
  心，TCP根据对方给出的窗口值和当前网络的拥塞程
  度来决定一个报文段包含多少字节
如果应用程序传送到TCP缓存的数据太长，TCP就把
  它划分短一些再传送，如果一次只发来一个字节，
  TCP也可以等待累积确认有足够多的字节再构成报文
  段发送出去
UDP发送的报文(数据)长度时应用程序给出的
可靠传输的工作原理:
  停止等待协议 —-很早很早网络还不是很稳定的时候
    一来一回的确认
    发送方超时重传(长时间没有收到确认)
    接收方重复的丢弃，但重复确认还是发送(B收到
      M1确认了，但丢失了，A重发M1，B再次收到
      M1丢弃，但对M1的确还是要再发一次的)
    迟到的确认什么都不干(B收到M1确认丢失了，A
      重发M1，B再次收到M1，丢弃并再次确认，
      这个再次确认A直接丢弃
    ARQ(Automatic Repeat reQuest)自动重
      传请求，就是说重传不是接收方请求的，而是
      发送方超时自动请求的
  连续ARQ协议和滑动窗口协议 —-累积确认，效率高
首部:20+40(选项) —-4bit最大15(15*4=60)
检验和:
  首部+数据+伪首部(12)
    伪首部(12):源IP(4)+目的IP(4)+0(1)
      +6(1:协议号)+TCP长度(2:数据+首部
      ，TCP首部没有长度字段，只有首部偏移，
      但IP首部有长度字段，可推算)
  TCP检验和把TCP报文段的首部和数据(报文)一起
    都检验，而IP数据报的检验和只检验IP数据报首部


// TCP机制1 —-可靠传输
发送窗口:以字节为单位的滑动窗口
  前沿:加入允许发送的的数据
        不动:没有收到新的确认，并且cwnd，rwnd
              还有发送缓存没有让发送窗口大小
              发生改变
            收到了新的确认，但是以上各因素让发
              送窗口缩小了，使得前沿正好不动
        向前:收到了新的确认
        向后:TCP标准强烈不赞成这样做，容易产生
              错误
  后沿:后沿再往后就是已经确认过的数据了
        不动:没有收到新的确认
        前移:收到了新的确认


超时重传


累积确认:接收方可以在合适的时候发送确认，也可以
           在自己有数据时把确认信息顺便捎上
         TCP标准规定，这个合适的时间不能超过
           0.5秒，如果收到一连串的具有MSS的报文
           段，必须每隔一个报文段就发送一个确认
         捎带确认实际上并不经常发生，因为大多数
           应用程序不同时在两个方向上发送数据


发送缓存和发送窗口:
  发送窗口通常只是发送缓存的一部分
  发送缓存与发送的窗口的后沿重合
  发送应用程序必须控制写入缓存的速率，不能太快，否则
    发送缓存就没有存放数据的空间


接收缓存和接收窗口:
  接收窗口是接收缓存的一部分，不能够超过接收缓存
  按序到达，已发送确认，尚未被应用程序读取的数据
  未按序到达的数据，前面数据还没到，自己到了
  如果接收应用程序来不及读取收到的数据，接收缓存
    终将会填满，rwnd为0


// TCP机制2 --流量控制
就是让发送方的发送速率不要太快，要让接收方来得及接收


发送方的放松窗口不能超过接收方给出的接收窗口的数值
  TCP的窗口单位是字节，不是报文段


如果rwnd=0，不允许发送方再发送数据了，直到B重新发送
  一个新的rwnd为止


死锁:B告诉A，rwnd为0，那么A等待B重新发来的rwnd不为
      0才能发送数据。如果B向A发送零rwnd报文段后不
      久，B的接收缓存又有了一些存储空间，B向A发送
      rwnd=400的报文段，但是这个报文段丢失了，于是
      A一直等待B发送rwnd非0的通知，而B一直等待A发
      送的数据，死锁
解决死锁:只要TCP的发送方接收到B的零窗口通知，启动计
         时器，如果计时器到了还是没收到零rwnd通知
         则发送一个零rwnd的探测报文段（1字节）
         B在确认这个报文段时给出现在的rwnd，如果
         Rwnd仍然为0，重置这个计时器




// TCP机制3 --拥塞控制
防止过多的数据注入网络中，这样可以使网络中的路由
  或链路不致过载


拥塞控制  全局性的过程 --涉及所有的主机，所有的
                           路由器（这也是为什么
                           网络卡，所有人都卡的
                           原因）


流量控制 点对点通信量的控制


发送方：拥塞窗口cwnd 发送方的 发送窗口<=拥塞窗口


慢开始：如果一开始就把大量数据注入网络，可能引起网络
        拥塞。较好的方法是先探测一下，即由小到大
        放大发送窗口（一开始cwnd设置为1MSS，
        实际上TCP用字节作为窗口单位，这里简单起见
        ，用报文段的个数作为窗口大小的单位，MSS也
        就是最大报文段大小），也就是说，由小到大放
        大拥塞窗口。
        每经过一次传输轮次RTTI，cwnd就加倍


拥塞避免：每经过一次RTTI，cwnd就加1，即cwnd按照
          线性规律缓慢增长，即“加法增大”，
          当cwnd到达ssthresh=16后执行拥塞避免
          算法


乘法减小：无论在慢开始阶段还是拥塞避免阶段，只要出现
          超时就把ssthresh减半，比如当cwnd等于
          24时发现超时了ssthresh／2=12，并且将
          cwnd重新设置为1MSS，并执行慢开始算法


———————————
快重传和快恢复：1990年新增的两个拥塞避免算法
  快重传:首先要求接收方每接受到一个失序的报文段后就
          立即发出重复确认，之前是等待自己发送数据
          时才进行捎带确认或者什么都不做，
          让发送方自己按照超时机制重传。
          比如M3没有收到，收到M4，确认M2，收到M5
          确认M2，收到M6确认M2。
        发送发只要连续收到3个确认重复就立即重传对方
          尚未收到的报文段，比如上面连续收到3个M2
          的确认，就立即重传M3，不必继续等待M3的
          计时器过期。
        快重传可以使整个网络吞吐量提高20%


  快恢复:连续收到3个对M2的确认，执行“乘法减小”，
          ssthresh减半，但是接下来不执行“慢
          开始”算法，即当前cwnd不设为1，而是
          把当前cwnd设为ssthresh的一半，然后
          开始执行“加法增大”
        有些快重传会把当前cwnd再增大一些，
          Ssthresh／2+3，因为发送端收到了3个
          对M3的确认，这3个分组不再消耗网络资源


  在采用快恢复算法时，慢开始算法只会在连接建立时使
    用，另外，如果不是收到3个重复M2的确认，而是
    确实发现M3超时了，还是会使用慢开始算法，即
    当前cwnd设为1MSS，并且ssthresh／2


  发送方窗口的上限 = Min[rwnd, cwnd]
    其实最终还不能超过发送缓存的大小
    另外还要考虑rwnd发送到发送端的时间滞后，导致
      发送窗口受rwnd影响有一定的网络延迟


// TCP机制4 —-连接管理
3次握手
4次挥手


// TCP建立连接为什么最后ACK
A Sync1 B
B没收到，A再次Sync2B
  B收到，B Sync ack A
  A ack 连接完成


如果后面Sync1又到B，B ack
  如果此时没有3次握手的最后ack则认为连接建立了
    显然不合理


// TCP结束为什么2MSL
1. 为了保证A最后发送的ack没够到达B 在此期间如果B
     没有收到A的ack，B会重新发送fin+ack，如果A不
     等2MSL，此时A已经关闭，不会再发ack，也就是
     B无法正常关闭


2. 防止上一节提到的“已失效的连接请求报文段”出
     现在本连接中。
       在2MSL期间，就可以使本连接持续的时间内所
       产生的所有报文段从网络中消失


附. B收到A的Ack后，就进入closed状态，B比A结束
      TCP连接时间早


附. 保活计时器 客户端每收到一次客户的数据 重新
      设置保活器 通常2小时 若2小时没收到，就每隔
      75分钟发一次探测 如果10次探测还无响应，就
      关闭连接


// socket的各项参数设置
.阻塞与非阻塞，默认阻塞，通过fcntl(F_SETFL,\
  SOCK_NONBLOCK)设为非阻塞
  accept,send,recv,connect默认阻塞
  非阻塞I/O系统调用，立即返回，而不管事件是否发生
    如果没有立马发生，返回-1，这和出错一样，我们
    通过errorno来区分，对accept，send，recv
    而言，事件未发生errorno被设置为EAGAIN(再
    来一次)，或者EWOULDBLOCK(期望阻塞)，对
    connect而言，errorno被设置成EINPROGRES\
    S(在处理中)