1. TCP与UDP的总结
首先要引入一个端口号的概念
我们的ip可以识别互联网中的一个主机，而端口号可以识别出在主机上需要传输的到应用程序中。
TCP与UDP都是传输层的主要协议，但是他们却大不相同。
1.1 UDP协议
UDP传输协议是不保证传输的协议，它并不会保证数据在传输时是否到达目的主机。
1.2 TCP协议
TCP传输协议是面向连接的协议，它是会保证数据完整地传输到目的主机上去。
但是这并不能说TCP就一定比UDP好，因为面对不同的应用场景，两个协议都有优劣。比如在传输需要保证实时性的时候，
比如打微信电话，如果网络出现拥塞或者手机网络不好的情况下，我们可能一两句话没办法听到，但是这并不影响我们这次通话的内容。
所以丢失一些数据可以接受，我们就可以使用UDP协议，而TCP协议的丢包重传机制就多余。
但是在传输需要保证安全性的时候，TCP的确认机制和丢包重传机制就很适合。
1.2.1 TCP协议的特点：
为了保证传输的可靠性，我们就需要考虑很多情况，例如数据的破坏、丢包、重复以及分片顺序的混乱等问题
而TCP通过校验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现传输的可靠性。
1.2.2 通过序列号与确认应答提高可靠性
在我们日常生活中，我们与大屁股舍友交谈，对方说着说着突然目光呆滞，这时我们就需要突然辱骂对方，来检查对方是否在听你说话，
如果你的舍友大怒并且及时地嘴臭回你的话，那么他就是还在听你说话，只不过装作没听，只是在钓鱼。
但是如果你的舍友无动于衷，并且他还一边点头还一边对你笑的话，那么或许他喜欢被辱骂的感觉，或许就是他真的走神了。
（但是我的舍友大部分时间还是前者比较多一点）
在TCP协议中，由发送端发送数据到接受主机时，接收端主机会返回一个已接收到的确认应答的通知（ACK），
这样就实现了确认对方主机还能接收数据。
我们日常去上课的时候，老师总会书接上文，问我们上节课讲到哪里了。大部分时候我们都会真的说上节课上到哪里，
但如果是我的摸鱼舍友去上课，对于他来说，他上课没有听过课，没有接收过老师的信号就不知道老师讲到哪里了。
而我们跟老师确认教学进度的这个过程可以同TCP的序列号相似，接收方在接受到数据后，需要返回一个带有序列号的消息，
这样就可以避免我们的接受方重复发送相同的数据了。
1.2.3 定时重传如何确定
超时重发是指重发数据前，等待确认应答到来的那个特定时间间隔。如果超过这个时间让那位收到确认应答，发送端将进行数据重发。
重发超时的计算既要考虑往返时间又要考虑偏差是有其原因的。根据网络环境的不同往返时间可能会产生大幅度的摇摆，之所以发送这种情况是因为发送数据包的分段是经过不同的路线到达的。
数据重发之后若还是收不到确认应答，则进行再次发送。此时，等待确认应答的时间将会以2倍、四倍的指数函数延长。
此外，数据也不会被无限反复地重发。达到一定次数后，如果仍然没有得到应答包，就会判断网络不可达或者是目的主机故障，会强制关闭连接。
并且通知应用通信异常强行终止。
1.2.4 连接管理
1.2.4.1三次握手（建立连接）
TCP在传输数据前需要进行一系列的操作确立连接的可靠性
1.首先需要向目的主机发送SYN，来请求建立连接。
2.接收端接收到连接请求后会向发送端发送一个SYN（建立连接请求）和ACK（针对发送端的SYN的确认应答）的包来来应答
3.最后发送端就会发送一个ACK（针对接收端的SYN包的确认应答）。
1.2.4.2四次挥手（断开连接）
1.客户端发送一个FIN包（请求切断连接）
2.服务端发送一个ACK包（针对FIN的确认应答）
3.服务端发送一个一个FIN包（请求切断连接）
4.客户端发一个ACK包（针对FIN的确认应答）
1.2.4.3 TCP以段为单位发送数据
在建立TCP连接的同时，也可以确认发送数据包的单位，我们也可以称之为“最大消息长度”（MSS）。
最理想的情况下，最大消息长度正好时IP中不会被分片处理的最大数据长度
MSS是在三次挥手时确认的。不管是发送数据还是重发数据都会按照这个大小发送。
1.2.4.4 利用滑动窗口控制提高速度
TCP协议如果客户端每次都已一个字段来发送数据后等待服务端发送确认应答，如果遇到链路延迟较大的时候，通信效率就会很低。
此时TCP就引入一个窗口的概念，即使在往返时间较长的情况下也可以保证通信的效率。
窗口大小就是指无需等待确认应答而可以继续发送的数据的最大值。
在客户端的数据传输以 段 的数倍大小传输数据，而服务端在确认应答时相应发送更大的确认应答。
这种机制实现了使用大量的缓冲区，通过对多个段同时进行确认应答的功能。
滑动窗口：客户端在传输数据过程中，一次性发送了一个窗口大小的数据（几个端大小），而服务端在确认时只发送了前一半的确认应答，
在客户端的窗口的缓存就会忽略前一半的数据，将缓存中后一半数据和后面需要发送的数据一起发送到服务端。这个就是滑动窗口的概念。
1.2.4.5 窗口控制与重发控制
在我们使用窗口传输数据时，会出现中间有包丢失的情况。
我们可以分为两种情况：
1.当我们的数据包都到达了接收端，但是接收端的确认应答有几个没有到达发送端，但是后续的确认应答已经到达发送端，
而之前的确认应答也无需重发。
2.当我们遇到发送端的数据包丢失，我们需要对数据进行重发，但是我们的窗口到达了一定的大小，我们只能在窗口大小的数据传输完成之后，
我们之前丢失的数据段才能重发。比如客户端需要发送是个段大小的数据，而发送的数据第二个段就在传输过程中丢失了，那么接收端就会不断发送
对于第二段数据的请求，而接收端只能在将全部的段发送完成之后，在重发第二段的数据。
1.2.4.6 流控制
发送端根据自己的实际情况发送数据，但是接收端可能处于一种高负荷的情况下无法接收数据。如此一来，接收端没来应该接收的数据丢弃的话，
就又会触发重发机制，会造成网络流量的无端浪费。
为了防止这种情况发生，TCP提供了一种机制可以让发送方知道接收方实际能够接受的数据量。这种机制叫做流控制。
它的具体操作是，接收端主机向发送端主机通知自己可以接收的数据大小。于是发送端会发送不超过这个限度的数据。这个大小限度就被称作窗口大小。
当发送端发送了自己的数据到达接收端后，接收端会在确认应答中带有自己的窗口值。
1.2.4.7 拥塞控制
有了TCP的窗口控制机制后，接收端和发送端并不是能发多少就一下子发多少的，还是要考虑互联网是一个公共的环境，而网络环境有时好有时坏。
当我们在网络坏的时候，我们还一下子发送大量的数据，那么网络就会更坏了，那我们的数据就更发不出去了。而我们就利用一个慢启动的算法得到一个数值，对发送量进行控制。
首先，为了在发送端调节所有需要发哦说你是个数据的量，定义一个“拥塞窗口”，在慢启动时，将这个拥塞窗口大小一开始设置为1个数据段发送数据，每接收到一次确认应答（ACK）
拥塞窗口的值就加1。在发送数据包时，将拥塞窗口的大小与接收端主机通知的窗口大小进行对比，按照比较小的值还小的数据量发送数据。
如果重发采用超时机制，那么拥塞窗口的初始值可以设置为1以后再进行慢启动。
有了以上机制可以避免网络拥塞的发生。
|