TCP的可靠传输具体指的是什么？
TCP又称为可靠传输协议，这个可靠是指数据一定可以毫无遗漏的交给对方。但是是不是说我们开发了一个应用程序给另一个应用程序发送消息，他就一定能够收到呢？我们开发的时候用了TCP，而且TCP又是可靠的传输协议，那为什么我们的应用程序依然要处理要处理消息丢失，消息完整性校验等问题？
其实TCP的可靠传输是对于传输层来说的，这个可靠传输指的是TCP和TCP之间，TCP协议保证的是所有安装了TCP软件的程序之间的可靠传输。而对于我们开发者来说，我们开发的应用程序属于应用层。而我们开发或者日常生活中遇到的消息丢失，通常发生在传输层和应用层者之间。
那么TCP是如何做到可靠传输的呢？
首先TCP是一种面向有链接的协议，首先经过三次握手建立连接，只有在确认通信对端存在时才会发送数据。
ACK和超时重发机制
TCP首先会按照顺序给发送的数据标上号码。TCP每发送一个数据报，都会期待一个接收端ACK的回复，我们就知道接收端已经收到消息了。如果短时间内没有收到ACK，那么TCP就会对消息进行自动重发。
未收到ACK就说明消息一定就丢了吗？也不一定，有可能接收端收到消息了，返回ACK的途中发生了丢失。这个时候这个时候依然会进行超时重发。接收端可能会收到同样的消息，没关系我们不是对发送的数据进行编号了吗，如果接收端收到重复消息直接丢失就可以了。
TCP并不会无脑的进行重发，再尝试了一段时间后如果还是没有收到ACK，这时候它就会单方面的断开自己的链接，并通知应用层我无能为力了，你刚才让我发送的数据我确实发了，但是我一直没有收到ACK啊！这时候接收端的TCP就有点傻眼了，完全不知道发送了什么事情，我消息接受的好好的，我也给你发送了ACK（虽然丢失了），怎么你突然不给我发送数据了，还和我断开连接了？那么这时候有个问题，接收方的TCP应用程序是否应该将接收到的报文段交付给上层应用层程序呢？这并不是这篇文章的重点等以后有机会我再细化一些这里，暂时先留个疑问。
滑动窗口
好了我们通过ACK机制和超时重发，就做到了可靠传输，但是一个数据报成功发送需要一个来回，每次都要ACK这样串行化发送效率太低了。但是如果一股脑的把所有数据都发送出去就太浪费流量，对方的TCP软件挂了我们还在无脑发送。所以我们就一部分一部分的发送，这时候就有了滑动窗口技术。
现在假设我们有一个http报文被分成了9组发送1、2、3、4、5、6、7、8、9。如果按照刚刚的逻辑来看，肯定先发送1。当1确认了之后再发送2以此类推。
这时候我们限定滑动窗口的大小为5，就规定了滑动窗口覆盖这个范围1~5的数据可以并行发送出去
如果这时候接收端收到了1，并且返回了1的ACK，这时候窗口就会滑动一下，这时候6又可以被发送了.
当然接收方也可以进行累计确认，并不一定对每个分组都发送ACK。假设接收方收到了1、2、3这3个分组，接收方只需要对分组3进行确认。这时候发送方收到了3的ACK，就代表3之前的数据你都已经收到了，我就将窗口移动到4。
当然滑动窗口也有不足的地方，如果接收方收到分组1，2，4，5的数据而分组3丢失了，那么这时候只能返回分组2的ACK。4，5不能返回。因为如果一旦返回了4或5就代表4或5之前的数据我都已经收到了。当然发送发需要重新发送3、4、5。
TCP的窗口分为发送窗口和接受窗口，发送窗口的大小由接受端的能力决定。一般接收端报文确认的时候，会在TCP首部设置窗口大小。发送端接收到了确认会调整自己发送端涌口的大小，直到发送窗口的大小变为0就会暂停发送数据。这种发送暂停的状态会持续到发送端发送一个新的窗口值为止。
为什么要调整窗口呢？首先发送窗口是根据接收方的接收能力来决定的，假设一些数据已经到了接收端缓存，但是应用程序一直还没来得及获取，那么这时候就需要不断缩小窗口，不然发送端一直傻傻等待发送端报文，岂不是拜拜浪费资源了。
拥塞控制
一般来说，计算机网络都处在一个共享的环境中。因此也有可能因为其他主机之间的通信使得网络拥堵。如果网络拥堵的时候，我们发送端再发送一个较大的数据，极有可能就使得整个网络瘫痪了。又或者路由器没有足够的缓存空间，那么就会丢弃一些新来到的分组。然后TCP又进行了多次重传，造成了网络拥堵家具。
TCP为了防止这类问题，引入了一个新的窗口变量称为“拥塞窗口”，拥塞窗口的大小取决于网络环境。
在调节拥塞窗口大小的时候，首先会经历一个慢启动过程，首先将这个拥塞窗口的大小设置一个较小值，之后受到每一次ACK拥塞窗口的值会慢慢增加。发送数据包的时候，将拥塞窗口的大小与接收端主机通知的滑动窗口的大小作比较，然后取他们当中较小的值来确定发送端滑动窗口的值。
随着通信的进行，拥塞窗口也会越来越大，确认应答的数据也会增加，网路通途量也就逐渐上升，如果随着网络拥堵发发生吞吐量也会下降。这时候再调整阻塞窗口的大小，减少发送端滑动的的值就做到了拥塞控制。
