目录
TCP与UDP的区别
UDP协议
TCP协议
确认应答机制（安全机制）
超时重传机制（安全机制）
连接管理机制（安全机制）
三次握手
三次握手的作用：
四次挥手
滑动窗口（效率机制）
流量控制（安全机制）
拥塞控制（安全机制）
延迟应答（效率机制）
捎带应答（效率机制）
其他特性：面向字节流
TCP与UDP的区别
TCP 面向连接（如打电话要先拨号建立连接） ;UDP 是无连接的，即发送数据之前不需要建立连接TCP 提供可靠的传输。通过 TCP 连接传送的数据，无差错，不丢失，不重复，且按序到达 ; UDP尽最大努力交付，即不保证可靠交付UDP具有较好的实时性，工作效率比TCP高，适用于对高速传输和实时性有较高的通信或广播通信。每一条 TCP 连接只能是点到点的 ; UDP 支持一对一，一对多，多对一和多对多的交互通信TCP 对系统资源要求较多， UDP 对系统资源要求较少如果要传输比较大的数据包,TCP优先，UDP限制大小为64KB
TCP：有连接，可靠，面向字节流，全双工
端口号：占2个字节写一个服务器的时候必须手动指定一个端口号，用来区分不同程序。但写客户端的时候不用手动指定，系统会自动分配。
1-1023称为知名端口号，给一些比较知名的服务器使用例如：22为ssh服务器，80为http协议，443为https服务器。1024-65535为普通端口号。
UDP协议
我们学习一个协议时，最主要的就是要学习它的报文格式：
UDP报头:一共占8个字节，每一个部分都各占两个字节。
UDP报文长度：占2个字节，最长65535即64kb，这个长度是定长的，不能最初修改。
校验和：发送方把要发送的数据data1通过一定的算法，算出一个校验和sum1，并存入UDP报头，并通过网络一起把data和sum1一起发送出去，此时接受放收到数据data2，通过算法计算出校验和sum2，如果sum1不等于sum2那么data2数据与data1一定不同，如果相同，那么data1与data2大概率也相同。通过此方法就能法相在传输过程中数据是否传输错误。那么校验和具体怎么算，可以用CRC（循环冗余算法），也可以使用md5，通过md5生成的校验和都是定长的，分散的，不可逆的。
TCP协议
注意
4位首部长度：TCP报头长度最短是20字节，最长是60字节，4 bit=15，此处是以4字节为单位（选项都是以4字节为单位）。
校验和：同UDP
确认应答机制（安全机制）
超时重传机制（安全机制）
确认应答描述的是一个比较理想的情况，但是如果数据在网络传输过程中出现了丢包现象该如何处理呢？
有的同学可能会好好奇为什么会出现丢包的情况，其实，把网络想象成一条高速公路，路由器或者交换机想象为收费站，把一个一个数据包可以想象成一辆一辆的车，在普通情况下，这些车辆都可以快速通过收费站，但在特殊情况下例如节假日，这时车流量就非常的大，就会出现堵车的情况，但是当路由器针对堵车的处理是非常粗暴的，并不会把这些挤压得数据保存好，而是直接丢弃！这样数据就在网络中消失了。
由于丢包是一个随机的事件，因此在tcp传输过程中，丢包会出现两种情况：
1.传输的数据丢了
- 1.这个等待时间是可以配置的，不同系统上可能不一样，也可以通过修改一些内核参数来引起这里的时间变化。
- 2.等待的时间是动态变化的每多经历一次超时重传，等待的时间都会变长，当如，这个时间也不是无限拉长的，当达到一定的程度，这个时候就会触发tcp的重置连接操作了。
那么还有一个问题，如果返回的ack数据包丢了，实际上数据是已经发送到接收方B，那么重传以后，此时B就收到了两条一样的数据，这个时候会对程序带来bug吗？其实 TCP已经帮我们处理好了这样的情况，当我们再发送一个数据时，接收方如果发现接受缓冲区中存在该数据，那么就会直接丢弃掉确保read的时候只读到一条数据。接收缓冲区不仅仅能去重，还能进行重排序，确保发送顺序和接收顺序一致。
连接管理机制（安全机制）
在正常情况下，TCP要经过三次握手建立连接，四次挥手断开连接
三次握手
那么3次握手变成两次握手可以吗？变成4次握手可以吗？
4次握手是可以的，但是没有必要。两次握手是不行的。
三次握手的作用：
1.确认当前网络是否通畅
2.让发送方和接收方都能确认自己的发送能力和接受能力正常
3.让通信双方在握手的过程中，针对一些重要的参数进行协商比如tcp的序号从几开始，每次建立的时候，都会协商出一个比较大的，和上次这个设定可以避免“前朝的剑，斩本朝的官”，比如当网络不好时，客户端与服务器会尝试重连，如果这个时候旧连接的数据姗姗来迟那么这种迟到的数据就应该丢掉，不应该影响现在的业务逻辑，那么如何区分这个数据是来自前朝还是当朝呢？就可以通过tcp的序号来判断，当接收方发现接收到的数据和序号和当前数据的序号差别非常大，就可以认为这个数据是前朝的就可以直接丢弃掉。
四次挥手
可能有的同学会有疑问,B的ACK和FIN可不可以也合并，这是不一定的,因为ACK应带报文是直接由内核响应的，当B收到FIN就会立即返回ACK而FIN是由程序的代码触发的，需要调用close（）方法才会触发，当服务器返回ACK到代码执行到close发起FIN要经历多少时间是不确定，要看代码写了多少，但是TCP收中还有一个延时响应机制，能够拖住ACK的返回时间那么就有可能和FIN是同一时刻，那么此时就可以合并。
滑动窗口（效率机制）
TCP的可靠传输会影响传输的效率，滑动窗口可以缩短确认应答的等待时间，就可提高传输效率。
原本是每收到一个报文才发送一个数据：
但引入滑动窗口只是，就不等ACK回来就直接发送下一个数据，，但批量传输也是有上限的，达到上限之后，再等待ack，批量传输的数据多少就是滑动窗口的大小。
当A给B批量发送了4份数据，此时A已经达到滑动窗口的大小，就不能再发数据了，当收到一一条ACK之后才能再发数据，窗口越大，等待的ack就越多，此时传输速率就越高。但如果在活动窗口丢包了该如何处理呢？
1.ack丢了：没有任何影响，如果是1001这个ack丢了，但是2001这个ack到了就表示2001之前的数据都传输成功了。
2.数据包丢了：返回的ack就一直是相同的，这时主机A连续收到相同的ACK就会重传
动窗口确实会提高传输效率，但窗口设置得越大传输效率就越大吗？如果传输速度太快，那么接收方的数据就可能处理不过来了，此时接收方就会出现丢包的情况
流量控制（安全机制）
拥塞控制（安全机制）
流量控制是考虑对方的接收能力，拥塞控制就是在通信过程中的节点情况，由于中间某一个节点已经达到了处理能力的上限，那么对传输速率也是会有影响的。
我们可以让A先以一个较低的速度发送，如果这个过程非常顺利，并且没有包丢失的情况，那么尝试增大速率，随着速率增大即窗口大小不停增大，达到一定程度过后，中间节点就可能出现问题，出现数据包丢失的情况，这个时候，就把窗口的大小调整小，如果还是丢包就调整更小，发现不丢包以后就尝试逐渐变大。
延迟应答（效率机制）
正常情况下，当A把数据传送给A,此时会立即返回ACK，但是有的时候A传输给B之后，此时B会等一会再返回ACK，本质上是提升传输效率，延时返回ACK就是给接收方更多的时间来读取缓冲区的数据，此时返回缓存区的剩余空间就更大。
捎带应答（效率机制）
捎带应是再演示应答的基础上实现的，假设主机A给主机B发送了一个请求，正常情况下会立即返回一个ACK，但由于tcp引入了延时应答的机制就没有立即返回，由于response是的应答时间要根据实际代码情况来定，如果此时response正好要返回，与此同时顺便就把刚要返回的ACK也一起捎带上了。
其他特性：面向字节流
在这里有一个粘包的问题，当多个应用从数据从A传输给B时，此时，会先进入B的接收缓冲区，在从接收缓冲区读取数据，但TCP是面向字节流的，每次从缓冲区读取多少数据都是随机的，可以读取一个字节也可以读十个字节，但最终的目的都是为了得到一个完整的应用层数据包，B程序就不知道从哪儿到哪儿才是一个完整的数据包。
那么如何解决这样的粘包问起呢？
- 1.引入分隔符:在网络编程的时候一个设计到用\n作为分隔符，那么此时传输数据时候，每传输完一个数据，就在其后加入\n，在读取数据的时候，读到\n时就代表这段数据读完了。
- 2.引入长度:在传输数据的时候标明一共传输的长度，读取数据的时候就按照这个长度来读取。