1. TCP 协议是一个面向连接，可靠的，字节流服务的协议
面向连接是指通信双方交换数据之前必须建立连接，可靠性是指拥有多种确保可靠性的机制，8位字节流为最小单位构成的字节流。这里主要先阐述下TCP是一种流模式的协议的含义：
举个形象的例子：
TCP流模式：你家里有个蓄水池，你可以里面倒水，蓄水池上有个龙头，你可以通过龙头将水池里的水放出来，然后用各种各样的容器装(杯子、矿泉水瓶、锅碗瓢盆)接水。往水池里倒几次水和接几次水是没有必然联系的，也就是说你可以只倒一次水，然后分10次接完。另外，水池里的水接多少就会少多少;往里面倒多少水，就会增加多少水，但是不能超过水池的容量，多出的水会溢出。结合TCP的概念，水池就好比接收缓存，倒水就相当于发送数据，接水就相当于读取数据。好比你通过TCP连接给另一端发送数据，你只调用了一次 write，发送了100个字节，但是对方可以分10次收完，每次10个字节;你也可以调用10次write，每次10个字节，但是对方可以一次就收完。 (假设数据都能到达)但是，你发送的数据量不能大于对方的接收缓存(流量控制)，如果你硬是要发送过量数据，则对方的缓存满了就会把多出的数据丢弃。
UDP数据包：发送端调用了几次write，接收端必须用相同次数的read读完。UPD是基于报文的，在接收的时候，每次最多只能读取一个 报文，报文和报文是不会合并的，如果缓冲区小于报文长度，则多出的部分会被丢弃。也就说，如果不指定MSG_PEEK标志，每次读取操作将消耗一个报文。
2.TCP连接的端口称为插口，或者套接字，套接口，插口和端口、IP地址的关系如下：
3.TCP报文段格式(面试可能要求现场画出来)：
MSS是TCP报文段中数据字段的最大长度，数据字段加上TCP首部才是整个TCP报文长度
4.TCP三次握手
第一次握手：客户端发送SYN报文，同时随机生成了一个序列号SEQ=x
第二次握手：服务端SYN+ACK报文，此时服务端也会随机生成一个序列号SEQ=y，同时ACK回应的时候领ACK=x+1
第三次握手：客户端发送ACK报文 ACK=Y+1
上次面试的时候，被面试官问了一个问题：TCP三次握手解决了什么？
个人理解：在这个过程中，两边协商了一个各自的序列号，这对后面的数据传输过程中进行报文确认和重组的重要依据
同时，这里也提供了接收方窗口的大小。
为什么是三次握手，而不是两次：
假设第三次握手不进行，假设客户端发送了第一个SYN报文给服务端，但是由于网络的延迟，服务器没有接收到，此时客户端没有得到服务器的应答，以为发送的包就丢失了，就启动了重新发送另外一个包，但此时第一个包被服务器接收了，服务器做出回应应开始建立连接，并等待客户端发送数据，但是客户端对已经丢失的包不会理睬，这样就会导致服务器再等客户端发送数据，客户端在等服务端建立连接。
5.TCP的四次挥手
1.客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2.服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
3.服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
4.客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。
为什么还要等待2MSL?
第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。
第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文
6.SYN泛洪
原理：在三次握手中，客户端发送数据包时包里的源IP是虚假IP，导致服务器在返回SYN数据包时不知道返回给谁
攻击端发出的响应报文将永远发送不到目的地，那么被攻击端在等待关闭这个连接的过程中消耗了资源，如果有成千上万的这种连接，主机资源将被耗尽，从而达到攻击的目的。我们可以利用路由器的TCP拦截功能，使网络上的主机受到保护(以Cisco路由器为例)
7.TCP确认机制
当分组报文到达服务端时，由于缺少了某段报文，服务端会向客户端确认并要求重发，如下图所示：
8.TCP流量控制：滑动窗口
可参考如下博文：https://blog.csdn.net/wdscq1234/article/details/52444277
补充：当窗口变为0的时候，发送端不能像往常那样发送数据，但是两种特殊情况除外，第一种是紧急数据仍然可以发送，它允许用户杀掉远程机器上运行的某个进程。其次，发送端仍可以发送一个字节，以便强制接收方重新宣告下一次期望的字节和窗口大小，这种数据包称为窗口探测
9.TCP计时器
TCP共使用以下四种计时器，即重传计时器、坚持计时器、保活计时器和时间等待计时器 。这几个计时器的主要特点如下：
1、重传计时器
当TCP发送报文段时，就创建该特定报文段的重传计时器 。可能发生两种情况：
（1）、若在计时器截止时间到（ 通常是60秒 ）之前收到了对此特定报文段的确认，则撤销此计时器。
（2）、若在收到了对此特定报文段的确认之前计时器截止期到，则重传此报文段，并将计时器复位。
2、坚持计时器
为了对付零窗口大小通知，TCP需要另一个计时器。假定接收TCP宣布了窗口大小为零。发送TCP就停止传送报文段，直到接收TCP发送确认并宣布一个非零的窗口大小。但这个确认可能会丢失。我们知道在TCP中，对确认是不需要发送确认的。若确认丢失了，接收TCP并不知道，而是会认为它已经完成任务了，并等待着发送TCP接着会发送更多的报文段。但发送TCP由于没有收到确认，就等待对方发送确认来通知窗口的大小。双方的TCP都在永远地等待着对方。
要打开这种死锁，TCP为每一个连接使用一个坚持计时器。 当发送TCP收到一个窗口大小为零的确认时，就启动坚持计时器 。 当坚持计时器期限到时，发送TCP就发送一个特殊的报文段， 叫做 探测报文段 。这个报文段只有一个字节的数据。它有一个序号，但它的序号永远不需要确认；甚至在计算对其他部分的数据的确认时该序号也被忽略。探测报文段提醒对端：确认已丢失，必须重传。
坚持计时器的值设置为重传时间的数值。但是，若没有收到从接收端来的响应，则需发送另一个探测报文段，并将坚持计时器的值加倍和复位。发送端继续发送探测报文段，将坚持计时器设定的值加倍和复位，直到这个值增大到门限值（ 通常是60秒 ）为止。在这以后，发送端每隔60秒就发送一个探测报文段，直到窗口重新打开。
3、保活计时器
保活计时器使用在某些实现中，用来防止在两个TCP之间的连接出现长时期的空闲。假定客户打开了到服务器的连接，传送了一些数据，然后就保持静默了。也许这个客户出故障了。在这种情况下，这个连接将永远地处理打开状态。
要解决这种问题，在大多数的实现中都是使服务器设置保活计时器。每当服务器收到客户的信息，就将计时器复位。保活计时器 通常设置为2小时 。若服务器过了2小时还没有收到客户的信息，它就发送探测报文段。若发送了10个探测报文段（每一个相隔75秒）还没有响应，就假定客户出了故障，因而就终止该连接。
4、时间等待计时器
时间等待计时器是在连接终止期间使用的 。当TCP关闭一个连接时，它并不认为这个连接马上就真正地关闭了。在时间等待期间中，连接还处于一种中间过渡状态。这就可以使重复的FIN报文段（如果有的话）可以到达目的站因而可将其丢弃。这个计时器的值 通常设置为一个报文段的寿命期待值的两倍 。
10.TCP拥塞控制
https://blog.csdn.net/jtracydy/article/details/52366461