TCP和UDP的传输过程以及TCP如何保障传输的可靠性
TCP和UDP都是传输层的协议，传输层的主要任务就是建立应用程序端对端的连接，并且为数据传输提供可靠或不可靠的通信服务。
TCP：提供面向连接的服务，在传送数据之前必须先建立连接，数据传送完成后要释放连接。
UDP：在传送数据前不需要先建立连接，远地的主机在收到UDP报文后也不需要给出任何确认。
TCP建立连接的过程？
TCP三次握手：
1、客户端向服务器发送连接请求，请求中包含连接请求的同步序号SYN=1和自身***seq=x。
2、服务器收到客户端的请求后，同意建立连接；向客户端发送一条确认报文，其中包含同步序号SYN=1，确认ACK=1，确认号ack=x+1还有自身***seq=y。
3、客户端收到服务器发来的确认报文之后会向服务器也发送一条确认报文，ACK=1，seq=x+1，ack=y+1。
4、当服务器收到客户端发送过来的确认报文之后，双方建立了连接，可以开始通信了。
TCP四次挥手：
1、客户端向服务器发送一条终止报文，包含终止序号FIN=1和自身***seq=u。
2、服务器收到客户端的终止报文后同意终止连接，会向客户端发送一条确认报文，包含ACK=1,seq=v，ack=u+1。
3、服务器在数据传送完毕之后再向客户端发送一条终止报文，其中包含FIN=1,ACK=1,seq=w，ack=u+1。
4、客户端收到服务器发送的终止报文之后，再向服务器发送确认报文ACK=1，seq=u+1，ack=w+1。
5、服务器收到客户端发送的确认报文之后便关闭连接，客户端则等待2*MSL时间之后才关闭连接。
MSL：最大报文存活时间。
UDP传输数据的过程？
在进行udp传输时，需要明确一个是发送端，一个是接收端。
udp的发送端：
1，建立udp的socket服务，创建对象时如果没有明确端口，系统会自动分配一个未被使用的端口。
2，明确要发送的具体数据。
3，将数据封装成了数据包。
4，用socket服务的send方法将数据包发送出去。
5，关闭资源。
udp的接收端：
1，创建udp的socket服务，必须要明确一个端口，作用在于，只有发送到这个端口的数据才是这个接收端可以处理的数据。
2，定义数据包，用于存储接收到数据。
3，通过socket服务的接收方法将收到的数据存储到数据包中。
4，通过数据包的方法获取数据包中的具体数据内容，比如ip、端口、数据等等。
5，关闭资源。
TCP如何保障传输的可靠性？
TCP保障传输可靠性主要方式有：
1、校验和
2、***
3、确认应答
4、超时重传
5、连接管理
6、流量控制
7、拥塞控制
校验和：
在数据的传输过程中将每个发送数据段都看作16进制的整数；将这些整数加起来，进位不能丢补在最后面，最后取反得到校验和。
发送方：计算校验和并且对校验和进行填充。
接收方：以相同的方式计算校验和并且与发送方的校验和进行比对。
如果接收方比对校验和与发送方不一致，那么数据一定传输有误。但是如果接收方比对校验和与发送方一致，数据不一定传输成功。
确认应答与***：
***：TCP传输时将每个字节的数据都进行了编号，这就是***。
确认应答：TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文。这个ACK报文当中带有对应的确认***，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。
***的作用不仅仅是应答的作用，有了***能够将接收到的数据根据***排序，并且去掉重复***的数据。这也是TCP传输可靠性的保证之一。
超时重传：
在进行TCP传输时，由于确认应答与***机制，也就是说发送方发送一部分数据后，都会等待接收方发送的ACK报文，并解析ACK报文，判断数据是否传输成功。如果发送方发送完数据后，迟迟没有等到接收方的ACK报文，这该怎么办呢？而没有收到ACK报文的原因可能是什么呢？
首先，发送方没有介绍到响应的ACK报文原因可能有两点：
- 数据在传输过程中由于网络原因等直接全体丢包，接收方根本没有接收到。
- 接收方接收到了响应的数据，但是发送的ACK报文响应却由于网络原因丢包了。
数据在传输过程中由于网络原因等直接全体丢包，接收方根本没有接收到。
接收方接收到了响应的数据，但是发送的ACK报文响应却由于网络原因丢包了。
TCP在解决这个问题的时候引入了一个新的机制，叫做超时重传机制。简单理解就是发送方在发送完数据后等待一个时间，时间到达没有接收到ACK报文，那么对刚才发送的数据进行重新发送。如果是刚才第一个原因，接收方收到二次重发的数据后，便进行ACK应答。如果是第二个原因，接收方发现接收的数据已存在（判断存在的根据就是***，所以上面说***还有去除重复数据的作用），那么直接丢弃，仍旧发送ACK应答。
那么发送方发送完毕后等待的时间是多少呢？如果这个等待的时间过长，那么会影响TCP传输的整体效率，如果等待时间过短，又会导致频繁的发送重复的包。如何权衡？
由于TCP传输时保证能够在任何环境下都有一个高性能的通信，因此这个最大超时时间（也就是等待的时间）是动态计算的：
在Linux中（BSD Unix和Windows下也是这样）超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。重发一次后，仍未响应，那么等待2500ms的时间后，再次重传。等待4500ms的时间继续重传。以一个指数的形式增长。累计到一定的重传次数，TCP就认为网络或者对端出现异常，强制关闭连接。
连接管理：
连接管理就是三次握手与四次挥手的过程，在前面详细讲过这个过程，这里不再赘述。保证可靠的连接，是保证可靠性的前提。
流量控制：
接收端在接收到数据后，对其进行处理。如果发送端的发送速度太快，导致接收端的结束缓冲区很快的填充满了。此时如果发送端仍旧发送数据，那么接下来发送的数据都会丢包，继而导致丢包的一系列连锁反应，超时重传呀什么的。而TCP根据接收端对数据的处理能力，决定发送端的发送速度，这个机制就是流量控制。
在TCP协议的报头信息当中，有一个16位字段的窗口大小。在介绍这个窗口大小时我们知道，窗口大小的内容实际上是接收端接收数据缓冲区的剩余大小。这个数字越大，证明接收端接收缓冲区的剩余空间越大，网络的吞吐量越大。接收端会在确认应答发送ACK报文时，将自己的即时窗口大小填入，并跟随ACK报文一起发送过去。而发送方根据ACK报文里的窗口大小的值的改变进而改变自己的发送速度。如果接收到窗口大小的值为0，那么发送方将停止发送数据。并定期的向接收端发送窗口探测数据段，让接收端把窗口大小告诉发送端。
拥塞控制：
TCP传输的过程中，发送端开始发送数据的时候，如果刚开始就发送大量的数据，那么就可能造成一些问题。网络可能在开始的时候就很拥堵，如果给网络中在扔出大量数据，那么这个拥堵就会加剧。拥堵的加剧就会产生大量的丢包，就对大量的超时重传，严重影响传输。
所以TCP引入了慢启动的机制，在开始发送数据时，先发送少量的数据探路。探清当前的网络状态如何，再决定多大的速度进行传输。这时候就引入一个叫做拥塞窗口的概念。发送刚开始定义拥塞窗口为 1，每次收到ACK应答，拥塞窗口加 1。在发送数据之前，首先将拥塞窗口与接收端反馈的窗口大小比对，取较小的值作为实际发送的窗口。
拥塞窗口的增长是指数级别的。慢启动的机制只是说明在开始的时候发送的少，发送的慢，但是增长的速度是非常快的。为了控制拥塞窗口的增长，不能使拥塞窗口单纯的加倍，设置一个拥塞窗口的阈值，当拥塞窗口大小超过阈值时，不能再按照指数来增长，而是线性的增长。在慢启动开始的时候，慢启动的阈值等于窗口的最大值，一旦造成网络拥塞，发生超时重传时，慢启动的阈值会为原来的一半（这里的原来指的是发生网络拥塞时拥塞窗口的大小），同时拥塞窗口重置为 1。
拥塞控制是TCP在传输时尽可能快的将数据传输，并且避免拥塞造成的一系列问题。是可靠性的保证，同时也是维护了传输的高效性。