一、分层结构¶

1、应用层 2、传输层(TCP/UDP) 用于传递信息，有两种方式——TCP和UDP，TCP是基于连接的，UDP不需要连接。 3、网络互联层(网络层) 本层任务是把TCP层传下来的数据加上目标地址和源地址。 4、网络接口层(数据链路层) 从中看到相邻两个设备的MAC地址，网络包才能送达目标地址。

二、使用DNS比较TCP和UDP差别¶

1、使用nslookup命令DNS解析www.baidu.com。

[root@localhost ~]# nslookup 
> www.baidu.com
Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
www.baidu.com   canonical name = www.a.shifen.com.
www.a.shifen.com    canonical name = www.wshifen.com.
Name:   www.wshifen.com
Address: 103.235.46.40

其中抓包如下:

2、使用set vc命令强制DNS使用TCP

[root@localhost ~]# nslookup 
> set vc
> www.baidu.com
Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
www.baidu.com   canonical name = www.a.shifen.com.
www.a.shifen.com    canonical name = www.wshifen.com.
Name:   www.wshifen.com
Address: 103.235.46.40

其中抓包如下:

3、经过转包分析，在使用UDP的情况下，只用两个包就可以完成DNS查询。但在使用TCP的情况下，要先用三个包来建立连接。查询结束后，又用4个包来断开连接。

三、TCP¶

3.1 Seq(序号)¶

表示该数据段的序号，一个Seq号的大小是根据上一个数据段的Seq号和长度相加得到的。假如数据段1的起始Seq号为1，长度为1448，那么数据段2的Seq号为1+1448=1449。 注意:TCP是双向的，双方都可以是发送方，所以各自维护了一个Seq号！

3.2 Len¶

表示该数据段的长度，这个长度不包括TCP头。 注意:Len=0不代表没意义!

3.3 Ack¶

确认号，比如甲发送了"Seq:x Len:y"的数据段给乙，那乙回复的确认号就是x+y。 注意:TCP的确认是可以累积的!

3.4 SYN¶

携带这个标志的包表示正在发起连接请求。因为连接是双向的，所以建立连接时，双方都要发起一个SYN。

3.5 FIN¶

携带这个标志的包表示正在请求终止连接。因为连接是双向的，所以彻底关闭一个连接时，双方都要发一个FIN。

3.6 RST¶

用于重置一个混乱的连接，或者拒绝一个无效的请求。

四、TCP三次握手¶

1、说明:事实上握手时Seq号不是从0开始的，之所以从0开始是因为Wireshark启用了Relative Sequence Number。(如果想关闭那个功能，在【Edit】-【Preferences】-【Protocols】-【TCP】-【Relative Sequence Number】取消对勾就可以。) 2、文字表达三次握手建立过程 (1)客户端:我能跟你建立连接嘛？我的初始发送序号是X。如果你答应就是ACK=X+1。 (2)服务器:收到啦，ACK=X+1。我也想跟你建立连接。我的初始发送序号是Y。 (3)客户端:收到啦，ACK=Y+1。

五、TCP四次挥手¶

1、文字表达三次握手建立过程 (1)客户端:"我希望断开连接(请注意FIN标志)"。 (2)服务器:"知道了，断开吧"。 (3)服务器:"我这边的连接也想断开(请注意FIN标志)"。 (4)客户端:"知道了，断开吧"。

六、TCP窗口¶

1、window size(win=)不代表发送窗口，而是在向对方申明自己的接收窗口。 2、当发送窗口是由接收窗口决定的时候，可以通过window size(win=)的值来判断；当发送窗口由网络因素决定的时候，只能大概推理。 3、发送窗口决定了一口气能发多少字节，而MSS决定了这些字节要分多少个包发完。如在发送窗口为16000字节的情况下，如果MSS是1000字节，那就需要发送16000/1000=16个包。 4、发送方在一个窗口里发出n个包，不一定就能收到n个确认包。由于TCP可以累积起来确认，所以当收到多少个包时，只需要确认最后一个就可以。 5、TCP Window Scale的作用是向对方声明一个Shift Count,我们把它作为2的指数，再乘以TCP头中定义的接收窗口，就得到真正的TCP接收窗口了。这里需要注意，有时候防火墙识别不了Window Scale，因此对方无法获得Shift count，最终导致严重的性能问题。

七、发送方避免触碰拥塞点¶

7.1 拥塞窗口维护过程¶

1、连接刚刚建立，发送方将拥塞窗口的初始值定的很小(RFC的建议是2个、3个或者4个MSS)。 2、慢启动过程:如果发出的包都得到确认，表明没有达到拥塞点，可以增大拥塞窗口。(RFC建议的算法是每收到n个确认，可以把拥塞窗口增加n个MSS) 3、拥塞避免:当慢启动过程持续一段时间后，此时拥塞窗口达到一个较大的值。触碰拥塞点的概率变大了，RFC建议的算法是在每个往返时间增加1个MSS。(从慢启动过渡到拥塞避免的临界窗口值很有讲究，如果之前发生过拥塞，就把该拥塞点作为参考依据；如果从来没有拥塞过，就可以取相对较大的值。)

7.2 重传¶

7.2.1 超时重传¶

1、定义:发送方迟迟收不到确认，就认定包已经丢失，只能进行重传。 2、超时重传产生的影响: (1)在RTO阶段不能传数据，相当于浪费一段时间 (2)拥塞窗口的急剧减小。 3、RTO:从发出原始包到重传该包的这段时间。

7.2.2 重传后拥塞窗口调整¶

1、重传之后窗口降到1个MSS，然后再次进入到慢启动过程。 2、把临界窗口值定为上次发生拥塞时没被确认的数据量的1/2.但不能小于2个MSS。以这个标准从慢启动过渡到拥塞避免的临界窗口值。

7.2.3 快速重传¶

1、定义:当发送方收到3个或以上重复确认时，就意识到相应的包已经丢了，从而立即重传它。

7.2.4 快速恢复¶

1、定义:把临界窗口值定为上次发生拥塞时没被确认的数据量的1/2.但不能小于2个MSS。然后将拥塞窗口设置为临界窗口值增加3个MSS，继续保留在拥塞避免阶段。

7.2.5 总结结论¶

1、没有发生拥塞时，发送窗口越大，性能越好。所以在带宽没有限制的条件下，应该尽量增大接收窗口，比如启用Scale Option。 2、如果经常发生拥塞，那限制发送窗口反而能提高性能，因为即便万分之一的重传对性能的影响都很大。在很多操作系统上可以通过限制接收窗口的方法来减小发送窗口。 3、超时重传对性能影响最大，因为它有一段时间(RTO)没有传输任何数据，而且拥塞窗口会被设为1个MSS，所以尽量避免超时重传。 4、快速重传对性能影响小一些，因为它没有等待时间，而且拥塞窗口减小的幅度没那么大。 5、SACK和NewReno有利于提高重传效率，提高传输性能。 6、丢包对极小文件的影响比大文件严重。因为读写一个小文件需要的包数很少，所以丢包时往往凑不满3个Dup Ack，只能等待超时重传了。而大文件有较大可能触发快速重传。

八、UDP¶

8.1 定义¶

面向无连接的传输层协议。

8.2 优点¶

1、在同样大小的包里，UDP携带的净数据比TCP包多一些。 2、由于UDP没有Seq号和Ack号等概念，无法维持一个连续，所以省去了建立连接的负担。

8.3 缺点¶

1、UDP没有重传机制，所以丢包由应用层来处理。 2、UDP不在乎MTU的大小，当拿到应用层数据后，直接打上UDP头交给下一层。(对于超过MTU，发送方的网络层负责分片，接收方收到分片后再组装起来，特别消耗资源。) 3、分片机制存在弱点，会成为黑客的攻击目标。当黑客持续快速地发送"More fragments"的flag为1的UDP包，接收方一直无法将这些包装起来，就很有可能耗尽内存。

Wireshark分析TCP和UDP