TCP提供了可靠传输，主要按照下面方法实现。
- 分块发送：应用程序被分割成TCP认为最适合发送的数据段。
- 定时确认重传：一端发送后会开启超时检测，如果在这段时间内都没有收到返回的“确认接收”的数据，就会重新发送一次。
- 收到数据后返回：当一端收到另一端的数据后，会发生一个确认收到的字段，但是这个字段不会立即发送，会推迟（小于1s）
- 数据校验：判断TCP的首部和数据的校验和是否正确，这是为了查看数据在传输过程中是否有被改变。如果校验和不对，那么接收端将丢弃这个报文。
- 正确排序：IP数据报到达可能会失序，所以TCP数据报也是一样，如果有必要，就会将数据报排序再转发给应用层。
- 重复丢弃：数据报会发生重复，将重复的丢弃
- 流量控制：每一端都有固定的缓冲区，接收端只能接受另一端发送接收端缓冲区所能容纳的数据。
1. 糊涂窗口综合症
发送端产生数据很慢，接收端接收数据很慢。
1. 发送端引起的解决方法
将发送端要发送的小数据保存起来，等到组成一个比较大的数据再进行发送。在这之间有限定时间，如果超过限定时间就直接把保存的数据发送。
2. 接收端引起的解决办法
使用滑动窗口，接收方在每一次接收到数据都会告诉发送方下次自己能接收多少数据。
应用程序消耗数据比到达的慢，有两种建议的解决方法
- Clark解决方法 Clark解决方法是只要有数据到达就发送确认，但通告的窗口大小为零，这个过程持续到缓存空间已能放入具有最大长度的报文段或者缓存空间的一半已经空了。
- 延迟确认：这时接收方不立即确认收到的报文段。接收方在确认收到的报文段之前一直等待，直到入缓存有足够的空间为止。该方法阻止了发送端滑动其窗口，当发送端发送完其数据后，它就停下来了。这样就防止了这种症状。延迟的确认还减少了通信量。接收端不需要确认每一个报文段。但它有可能使发送端重传其未被确认的报文段。可以给延迟的确认加一个时间限制来降低该方法缺点的影响。
2. 滑动窗口
TCP滑动窗口主要用于控制流量，避免发送端过多的发送数据而导致接收端超过了可承载的能力（超负载）
下面用一个例子解释滑动窗口：
假设现在有1-9这一组数据，被分成1-3,4-6,7-9三个部分发送，
此时发送端滑动窗口的范围为1-9，接收端可接收的数据为2组
接收端只接收到1-3,4-6，那么接收端就会返回ack=7，以及当前可接收的数据为1组
发送端收到ack=7时，便会认为1-6已经发送成功，
此时滑动窗口向右滑到7的位置，范围为7-9，
发送端滑动窗口的大小根据接收端可接收的大小而变化，
此时发送端继续发送7-9，接收端接收到7-9，返回ack=10，当前可接收数据为0组，
此时就是到了零窗口状态，说明接收端已经接收到所有数据或接收端保存到缓冲区，但此时应用程序还未接收信息，所以缓冲区为满
发送端接收到接收端的零窗口状态，就不再发送消息，直至接收端发送可接收数据的大小大于0，发送端才重新开始发送数据
