关于UDP及TCP的基本特性及网络编程，这篇博客里面已经总结过了，大家可以看看：http://t.csdn.cn/heRl2
目录
2.1.3、连接管理机制【安全机制】——(三次握手,四次挥手)
1、UDP协议：
UDP是User Datagram Protocol的缩写，该协议不需要连接，不稳定传输，面向数据报，全双工，简单且高效，但是它的数据载荷较小，一般适用于以下场景：
- 包总量较少的通信（DNS、SNMP等）
- 视频、音频等多媒体通信（即时通信）
- 限定于LAN等特定网络中的应用通信
- 广播通信（广播、多播）
UDP协议的格式：
注意：这里的图是竖着画的，实际上存储其实是横着的一排过去
UDP的报头里面的4个字段：
端口号即一种属于传输层的“地址”，就像数据链路和IP中的地址，分别指的是MAC地址和IP地址。MAC地址和IP地址是用来定位那一台主机，而端口号用来识别同一台计算机中进行通信的不同应用程序。
端口号本质上是一个16比特的无符号整数，即2字节，范围是0-65535，其中0-1023范围的端口号被称为知名端口号，用于非常常用的通信服务。
- 源端口号（2字节）：发送方的端口号。
- 目的端口（2字节）：接收方的端口号。
- 包长度，也叫报文长度：表示一个UDP数据报的大小，单位为字节，也就是说一个UDP数据报最大不超过64k。（如果UDP传输一个比较大的数据，就需要拆包，将一个大的数据报拆成多个小的）
- 校验和：用来验证网络传输的数据是否正确。
补充：
- 没有发送缓冲区（发了消息就不管），有接收缓冲区
- 在应用层代码中，针对数据包拆成多个UDP数据报，分别传输，开发中会比较复杂，测试起来也比较复杂，风险变高，所以一般会使用TCP，因为TCP是字节流，没有对包的长度做出限制~
基于UDP的应用层协议：
- NFS：网络文件系统
- TFTP：简单文件传输协议
- DHCP：动态主机配置协议
- BOOTP：启动协议（用于无盘设备启动）
- DNS：域名解析协议
注：还有自定义的协议
2、TCP【重点重点重点】
2.1、TCP协议段格式
TCP的报头里面的字段
TCP这里的源端口号与目的端口号的意思与UDP完全一样，表示发送方与接收方的端口号。校验和的作用与UDP也是一样的，但是TCP的校验和功能不能关闭，而UDP可以关闭。
数据偏移（头部长度），表示TCP数据起始处与TCP报文起始处之间的距离，其实就是TCP首部报头长度了，一共4比特，能表示0-15，单位为4字节，也就是说能表示TCP报头长度为0-60字节，基本上完全够用了，就算有一天不够用了，数据偏移后面还有6比特备用。
序号（）Seq：表示该报文段所发送数据的第一个字节的编号，在TCP连接中所传输字节流的每一个字节都会按顺序编号，由于序列号是由32位表示，所以每2^32个字节，就会产生序列号回绕，再次从0开始 。ACK=Seq+1
确认号：表示接收方期望收到发送方下一个报文段的第一个字节数据的编号，也就是告诉发送方：我希望你下次发送的数据的第一个字节数据的编号为此确认号
选项：可有可无也可以有多个，可能包括“窗口扩大因子”、“时间戳”等选项。长度可变，最长可达 40 字节，当没有使用选项时，TCP 首部长度是 20 字节。填充是为了保证选项为32比特的整数倍。
窗口大小：表示现在允许对方发送的数据量，也就是告诉对方，本报文段确认号开始允许对方发送的数据量，到达此值，需要ACK确认后才能继续发送数据
控制位，字段长为8比特，每一位从左至右分别为CWR、ECE、URG、ACK、PSH、RST、SYN、FIN。
具体含义（来源《图解TCP/IP》）
- CWR（Congestion Window Reduced）
CWR标志， 与后面的ECE标志都用于IP首部的ECN字段。ECE标志为1时，则通知对方已将拥塞窗口缩小。
- ECE（ECN-Echo）
ECE标志， 表示ECN-Echo。置为1会通知通信对方，从对方到这边的网络有拥塞。在收到数据包的IP首部中ECN为1时将TCP首部中的ECE设置为1。
- URG（Urgent Flag）
该位为1时，表示包中有需要紧急处理的数据。对于需要紧急处理的数据，会在后面的紧急指针中再进行解释。
- ACK（Acknowledgement Flag）
该位为1时，确认应答的字段变为有效。TCP规定除了最初建立连接时的SYN包之外该位必须设置为1。
- PSH（Push Flag）
该位为1时，表示需要将受到的数据立刻传给上层应用协议。PSH为0时，则不需要立即传而是先进行缓存。
- RST（Reset Flag）
该位为1时表示TCP连接中出现异常必须强制断开连接。例如，一个没有被使用的端口即使发来连接请求，也无法进行通信。此时就可以返回一个RST设置为1的包。此外，程序宕掉或切断电源等原因导致主机重启的情况下，由于所有的连接信息将全部被初始化，所以原有的TCP通信也将不能继续进行。这种情况下，如果通信对方发送一个设置为1的RST包，就会使通信强制断开连接。
- SYN（Synchronize Flag）
用于建立连接。SYN为1表示希望建立连接，并在其序列号的字段进行序列号初始值的设定（Synchronize本身有同步的意思。也就意味着建立连接的双方，序列号和确认应答号要保持同步。） 。
- FIN（Fin Flag）
该位为1时，表示今后不会再有数据发送，希望断开连接。当通信结束希望断开连接时，通信双方的主机之间就可以相互交换FIN位置为1的TCP段。每个主机又对对方的FIN包进行确认应答以后就可以断开连接。不过，主机收到FIN设置为1的TCP段以后不必马上回复一个FIN包，而是可以等到缓冲区中的所有数据都因已成功发送而被自动删除之后再发。
TCP数据段是可变的，可以简单的理解数据载荷没有限制。
其他的后面说~
2.1、TCP原理
可靠传输是TCP中最最最核心的特性！！！
2.1.1、确认应答机制【安全机制】
保证数据可靠传输的第一关就是确认应答，我们知道可靠性的核心就是发送方知道发送数据有没有被接收方收到，确认应答机制是实现可靠性的核心机制。
确认应答的关键就是发送方发送数据给接收方后，接收方会自动返回一个响应表示收到数据了。
举例：你和男朋友聊天时：
回复的 “ 可以呀！” 就是应答报文，也叫作ACK报文（acknowledge）
同时这里有一个点需要注意，在复杂的网络环境中，网络上通信传输路径是复杂的，两点之间，两个报文有不同的路线，会出现“后发先至”的情况，如下：
此时，你心里的小算盘想着，反正包包都有了，一个电影不看，无伤大雅！
这就是后发先至， 这是网络的基本结构导致的，难以避免，需要想一个办法，让含义不被误会
解决方案：针对请求和应答报文进行编号
在确认应答机制中，引入序号来保证不出现歧义：
32位序号：针对请求数据进行的编号
32位确认序号：只是针对ACK报文有效
注：TCP是一个字节流的协议，编号时也是以字节为单位
实际中的TCP传输中，是针对每一个字节进行编号，比如传输数据的序号是1，发送了1000个字节的数据，那么接收方收到数据后会返回一个1001，表示1001之前的数据以及全部收到了。
其中B给A回复的确认应答报文也被称为ACK，但是现实毕竟是现实，理想是理想，总会有意外，比如网络原因可能会导致发送数据或者ACK丢包了，丢包了怎么办？那只能重新传一个新的数据包呗，所以就有了下面的超时重传机制。
2.1.2、超时重传机制【安全机制】
超时重传是确认应答机制的一个补充，当出现丢包等情况时，超时重传就要“上阵”了。
当一个数据发送后，一定时间段内，没有收到确认应答，就会进行重发，当然重发不是无限制的，重发一定次数后就会降频重发或者就不会再重发了，因为在网络正常的情况下丢包的概率是很小的，两次以及多次丢包的概率那就更加小了。
触发重传有两种情况，一是数据丢了，那么发送方等待一段时间没有收到回应就会重新发送。
第二种情况，ACK丢包，对于发送方是不知道是自己这边发送的消息出问题还是对方发送的消息出问题了，就会按照最坏的情况，重发数据，这时候接收方会收到两份一样的数据，TCP发明者当然注意到这个问题了，于是就实现了一个去重机制，就是相同的数据不会被放入接收方缓冲区（有阻塞队列功能，但不限于阻塞队列）。由于数据相同，接收发会丢弃该数据，并发送一个与之前相同的ACK。
超时重传机制运行图：
2.1.3、连接管理机制【安全机制】——(三次握手,四次挥手)
对于TCP是需要建立连接的，所以就有了连接管理机制，其实也是保证可靠性的一种机制。对于TCP的连接管理就是三次握手，四次挥手。
客户端与服务器之间进行三次交互建立连接的过程被形象地称为“三次握手”
我们知道客户端是主动发出请求的一端，所以客户端与服务器建立连接时，首先客户端会向服务器发出一个连接请求，即SYN，然后服务器收到请求后会给客户端响应一个ACK和SYN，客户端收到服务器的SYN后会立即发送一个ACK给服务器，服务器收到客户端的确认应答后，客户端与服务器就连接成功了。其实严格来说应该有四步，只不过中间服务器响应的ACK与SYN合并为一条发送了而已
有没有觉得这里的SYN和ACK在哪里见过呢？这不就是TCP首部里面的控制位嘛。
其实发送SYN本质就是将SYN置为1，发送ACK的本质就是将ACK置为1，SYN与ACK同时发就是将这两位同时置为1，同理其他的也是如此。
在建立三次握手的过程中，服务器与客户端的状态不断在改变，三次握手更加详细的图如下：
上面的状态我们了解一下即可：
- CLOSED 表示客户端或服务器处于关闭状态
- LISTEN 表示服务器就绪，等待服务器连接状态，即绑定端口后（new ServerSocket完成），表示手机开机，信号良好，就可以让别人给他打电话~
- SYN_RCVD 表示服务器已经收到客户端的连接请求，发送ACK和SYN并进入阻塞等待客户端连接状态，一般此状态存在时间很短
- SYN_SENT 表示客户端连接请求已发送，此时客户端进入阻塞等待服务器确认应答状态，一般此状态的存在时间很短
- ESTABLISHED 表示客户端或服务器已经建立连接成功，随时可以进行通信，即表示电话接通了，可以说话了。
思考：为什么要进行建立连接？
- 答1：投石问路——检查当前网络的情况是否是畅通的（三次握手建立连接是不进行传输任何的业务数据的）
- 答2：三次握手同时也是在检查通信双方的发送能力和接受能力是否正常
当发送方发出SYN后，接收方都到发送方的SYN后，此时接收方就能够确定发送方的发送能力和接收方的接收能力是正常的，然后接收方回应ACK和SYN，当接收方收到ACK和SYN后，就知道了发送方以及接收方的发送能力和接收能力都是正常的，最后发送方回应ACK给接收方，此时接收方也确定了接收方以及发送方的接收能力和发送能力都是正常的。
举例：你和队友打游戏开麦时，会有一个试音过程：
如上述所说， 服务器响应的ACK与SYN合并为一条发送了，为什么可以合并，是因为ACK与SYN是ACK出发，SYN立即被出发，不会出现任何的等待，所以合并了：
- 答3：三次握手中，会协商一些重要的参数
既然有连接，那么自然会有断开连接的时候，客户端与服务器通过四次交互而断开连接的过程被称为“四次挥手”。
其中断开连接的请求也被称为FIN，FIN也是属于控制位家族的一员，此外四次挥手可以是客户端发起断开连接请求，也可以是服务器首先发起断开连接请求，我们以客户端主动断开连接为例。
首先，客户端发出断开连接FIN请求，然后服务器收到请求后立即响应ACK（内核返回ACK），服务器调用socket.close()方法后才会给客户端发送FIN（应用层返回FIN），所以服务器这里ACK与FIN发送的时机并不是在一起的，不像三次握手（时机相同，能够合并）能够合并ACK与SYN。而ACK，是在操作系统内核收到FIN时立即触发的，而再次发送FIN是应用程序，显示调用socket的close方法触发的，到底是不是同一时机，第一个不确定的事件，所以不将其合并。
同理，四次挥手过程中客户端与服务器的状态也在发生改变，我们来了解一下这些状态。
上图的主动方是客户端，被动方是服务器。
- FIN_WAIT_1 主动方发送FIN后，进入等待被动方确认断开响应状态
- FIN_WAIT_2 收到被动方的ACK，进入等待主动方FIN状态
- CLOSE_WAIT 当被动方收到主动方发送的FIN请求后，被动方响应ACK并进入准备关闭状态
- LAST_ACK 被动方FIN发送后，进入等待最后一个ACK状态
- TIME_WAIT 收到被动方FIN，发送最后一次ACK并进入最后等待状态
由于最后一次主动方发送ACK后可能存在丢包，如果丢包了，被动方就会以最坏情况认为自己的FIN丢了，会重发FIN，所以主动方需要等待被动方重发FIN，因此预留了一段时间用来等待被动方FIN重传，等待时间是2MSL，MSL表示报文最大生存时间，也就是在网络传输过程中的最大传输时间。如果等待过程中没有接收到FIN，服务器与客户端就断开连接了。
虽然可靠性是TCP最高机制，但是TCP会在可靠性保证的情况下尽量提升传输速度，所以为了在稳定性的基础上提升性能，引出了滑动窗口等机制。
2.1.4、滑动窗口【效率机制】
滑动窗口在保证传输的可靠性的前提下，尽量地提高传输效率。
我们不难发现，由于确认应答机制的存在，导致每执行一次发送操作，都需要等待ACK的到达，大部分的时间都用在等ACK上了。
滑动窗口的本质就是发送多组数据，然后等多组数据的ACK。
比如，客户端一次发送了4组数据，然后等ACK的到达，但并不是等4组数据的ACK全部到达后才继续发送数据，而是每收到一次ACK就发一组数据，比如如上图所示，客户端发出1-1000,1001-2000,2001-3000,3001-4000，四组数据后，客户端收到1001，就发送4001-5000，收到2001，就发送5001-6000以此类推。
这就相当于一个大小为4的窗口滑动，原来数据的范围是1-4000，收到一个1001确认应答响应后，数据的范围就变成了1001-5000，相当于窗口向右滑动了一格。
但是上面的是正常的情况，也就是没有考虑后发先制和丢包的情况，下面我们来讨论一下这几种情况：
情况1：后发先制
当出现1001-2000比1-1000先到达这种情况时，由于确认应答机制，收到1001-2000后，服务器会认为2001之前的数据已经全部到达了，因此会返回确认应答2001，客户端收到2001后，窗口会向右移动两格，传输的数据范围为3001-7000，只要1-1000的数据没有丢（如果他丢了，2001那里就不会返回ACK），没有任何影响，所以后发先制的情况，不用处理，数据仍然能够正常传输。
情况2：ACK丢了
这种情况其实与后发先制相似，比如1001丢了，当客户端收到2001时发送窗口就会右移两格，数据还是能够正常传输的，只要大部分的ACK没有丢，客户端可以通过下一次或者后面的确认应答序号来进行确认，所以ACK丢了不要紧，该情况也不用处理
举例：一个人有了大学生毕业证，那小学、初中、高中毕业证也是必然已经有的）【别杠】
情况3：数据丢了
这种情况不用想，肯定有问题，必须得处理的，比如1-3000的数据中，其中1001-2000的数据丢了，那服务器每收到一个数据，都会返回1001，表示让客户端重传1001-2000这个数据，当客户端收到若干个个相同的确认应答序号时，就明白了，数据丢了，就会对丢失的数据进行重传，直到服务器收到1001-2000的数据，就会返回最新的确认应答序号，这种机制也被称为高速重发控制。
那这么说，只要窗口越大，那么传输速度不就快了吗？你的窗口大了，发送方的发送速度确实提高了，但是接收方能接受得过来吗？如果发送速度过快，接收方的接收缓冲区满了之后，传来的数据就放不下了，就会造成数据丢失，那数据丢了不也还需要重传嘛。所以并不是窗口大小越大，传输效率就越高。只有保证发送方与接收方发送与接收的速率最大并保持一致时，传输效率才是最高的，因此为了做到这一点，就有了流量控制的机制。
2.1.5、流量控制【安全机制】
流量控制的关键就是得到处理方的处理速度，然后根据处理方的处理速度来动态调节发送的速度。
而此处是通过接收方缓冲区的剩余容量来衡量接收方处理速度的，发送方发送数据后会放到一个缓冲区，然后接收方通过这个缓冲区来读取数据，这样的一个过程也可以理解为生产者消费者模型，即发送方是生产者，接收方缓冲区是“交易场所”，发送方是消费者，当生产者的生产速度与消费者的消费速度到达平衡时，传输的数据既快又稳定。
不妨把这个接收方的缓冲区看作成一个水池，那么发送方的工作就是注水，接收方的工作就是使用水池中的水，当水位比较低（剩余空间大）那就注水的时候就快一点，水位比较高（剩余空间小）那就注水的时候就慢一点。
当发送方的数据到达接收方的时候，接收方都会返回一个ACK，这个ACK除了确认能够确认应答，还能告知接收方缓冲区的空间还剩余多少，然后发送方根据接收方缓冲区剩余的容量来控制发送速度（窗口大小），当接送方得知接收方缓冲区空间满了的时候，就不会去发送 数据，而是会去发送一个探测窗口报文，获取接收方缓冲区剩余空间的大小。
而上面的获取接收方缓冲区剩余空间大小，是通过TCP报头中的窗口大小来进行获取，占据16位（即64k），实际上这里的可描述的窗口大小不止64k，因为TCP报头选项中还包含选项，选项里面有一个窗口扩大因子M，实际窗口大小是将窗口大小字段左移M位，也就是扩大2 M 2^M2
M倍。
其中的窗口探测报文不包含任何数据，只是触发接收方响应ACK。
2.1.6、拥塞机制【安全机制】
拥塞控制是滑动窗口的延伸，也就是限制滑动窗口中数据的发送速度，拥塞控制描述的是从接收方到发送方之间链路的拥堵情况。
发送方发送的多快不仅取决于接收方的处理能力，还取决于中间链路的处理能力。而发送方与接收方中间的结点的个数我们是不得而知的，因此拥塞控制采取“测试实验”的方式来逐渐调整发送的速度。
一开始的时候接收方会以较小的窗口进行发送，通过逐渐提高窗口的大小，当窗口达到一定的大小，就会出现丢包的情况，这就意味着链路就出现了“拥堵”，这时候就会减小窗口的大小，是快速的减小窗口大小，因为如果出现丢包减小窗口大小的速度不够大，可能会出现持续性的丢包，对网络通信的质量会造成很大的影响。
关于拥塞窗口说明如下图：
2.1.7、延迟应答【效率机制】
延时应答，相当于流量控制的延伸，流量控制的目的是为了使发送方不要发送太快，而延时应答在此基础上，想让窗口的大小尽量大一点。
在延迟应答的基础上, 我们发现, 很多情况下, 客户端服务器在应用层也是 “一发一收” 的，意味着当客户端给服务端发送请求时，服务端会给客户端响应数据，如果稍等一会儿（几十ms），很可能在几十ms内，应用程序就从缓冲区取走一大波数据，此时延迟应答就会提高效率
举例：
就是发送方询问接收方窗口大小时，不立即做出回答，而是稍等一下在回答，比如一个水池，如果立即回答，回应的剩余空间是20吨，但如果等一下再应答，可能回应的剩余空间是28吨（因为接收方是一直在处理数据的），这样就能使窗口的大小尽量大一点。
接收端响应的ACK，和主动发送的数据，可以合并返回。
2.1.8、捎带应答【效率机制】
捎带应答是延迟应答的延伸，由于延时应答的存在，ACK并不是立即就发送响应的，当应用层代码需要响应时机与ACK响应时机重合时，就会将这两个数据合二为一，这就是捎带应答。
2.2、其他特性
（1、面向字节流
面向数据流中，一个典型的问题——粘包问题【在后面】
（2、缓冲区
（3、大小限制
创建一个TCP的socket，同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区；
- 调用write时，数据会先写入发送缓冲区中；
- 如果发送的字节数太长，会被拆分成多个TCP的数据包发出；
- 如果发送的字节数太短，就会先在缓冲区里等待，等到缓冲区长度差不多了，或者其他合适
- 的时机发送出去；
- 接收数据的时候，数据也是从网卡驱动程序到达内核的接收缓冲区；
- 然后应用程序可以调用read从接收缓冲区拿数据；
- 另一方面，TCP的一个连接，既有发送缓冲区，也有接收缓冲区，那么对于这一个连接，既
- 可以读数据，也可以写数据。这个概念叫做 全双工
由于缓冲区的存在，TCP程序的读和写不需要一一匹配，例如：
2.3、粘包问题
粘包问题，就是应用层去取缓冲区的数据时，会出现分不清哪些数据是哪些TCP数据包里面的应用层数据，那也很可能就不知道从哪里到哪里是一个完整的应用层数据报·，就造成了粘包问题，其实不止TCP传输存在这种问题，所有面向字节流读文件都会有这种问题。
举例理解：你将馒头放在一起蒸，但由于放的太近了，蒸好后，都是一个粘着一个，就会出现拿到半个或者一个半的情况。
那么要怎么解决呢？由于是找不到应用层的数据始末，所以去TCP上面做功夫是不可行的，问题出在哪里，就要在哪里解决，毕竟解铃还须系铃人。所以解决办法就是在应用层协议中加上包与包之间的边界，比如在应用层数据报结尾加上一个;，这样在读取的时候，就能区分出一个完整的应用层数据报了。【UDP不存在该问题】
2.4、TCP异常
进行TCP协议传输时会出现以下几种情况：
程序崩溃：
在进程毫无准备的情况下，突然异常结束进程，偷袭它，其实它有闪，会偷袭失败。
我们知道TCP连接是通过socket来进行连接的，socket本质上是进程打开的一个文件，文件就存在与PCBZ中的文件描述符表之中，每次打开一个socket文件都会在文件描述表中添加一项，删除会减少一项。
当你强制结束进程时，PCB没了，里面的文件描述符表也没有了，就相当于文件自动关闭了，这个过程和手动调用socket.close方法没有区别，依然会执行四次挥手过程。
机器关机：
机器关机和进程终止是一样的，首先会将PCB全部杀死，然后再进行关机，四次挥手依然会进行。
机器断网/断电：
当电源或网络直接断开时，端电时没有任何时间留给操作系统去反应，所以根本来不及去四次挥手，断网数据都发不出去，那四次挥手也无法成功。
当客户端断电或断网时，服务器就会尝试重新建立连接，，重连失败一定次数，就会放弃连接。
当服务器断电或断网时，客户端会发送一个探测报文，触发服务器的ACK，如果没有反应，客户端就认为服务器出现了问题。
总结一下，UDP与TCP之间的比较，UDP的传输效率高于TCP，但传输的文件较小和对可靠性要求不高时优先使用UDP。TCP是在保证可靠性的前提下，尽可能地去提升效率，但是还是有效率牺牲的，所以TCP的传输效率不如UDP，但是可靠性优于UDP。
2.5、基于TCP应用层协议
- HTTP
- HTTPS
- SSH
- Telnet
- FTP
- SMTP
注：包括在写TCP程序时自定义的应用层协议
2.6、TCP小结：
可靠性：
- 校验和
- 序列号（按序到达）
- 确认应答
- 超时重发
- 连接管理
- 流量控制
- 拥塞控制
提高性能：
- 滑动窗口
- 快速重传
- 延迟应答
- 捎带应答
其他：
- 定时器（超时重传定时器，保活定时器，TIME_WAIT定时器等）
下期见啦！！！
1612
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
