TCP可靠传输
TCP****可靠传输的工作原理
1**.**无差错
1>：无差错： A发送分组M1，发送就暂停发送，等待B的确认，B收到M1就向A发送确认，A收到对M1的确认后再发送下一个分组。（若A收到连续的M1分组的确认信息，则证明M2缺失）
2>：出现差错：
A只要超过一段时间仍然没有收到确认，就认为刚才发送的分组丢失了，就重传前面发过的分组，叫超时重传。由重传计时器实现。
而且：
（1）A每次发送分组必须暂时保留分组副本；
（2）分组和确认分组必须进行编号‘
（3）超时计时器的重传时间应当比数据在分组的平均往返时间更多一些。
3>：如果B收到重复的分组M1,不向上一层交付；而且，向A发送确认。
2**.**超时重传
其原理是在发送某一个数据以后就开启一个计时器，在一定时间内如果没有得到发送的数据报的ACK报文，那么就重新发送数据，直到发送成功为止。第一次发送后所设置的超时时间实际上为1.5秒，此后该时间在每次重传时增加一倍，一直到64秒，采用的是指数退避算法。一共重传12次，大约9分钟才放弃重传，该时间在目前的TCP实现中是不可变的，Solaris2.2允许管理者改变这个时间，tcp_ip_abort_interval变量。且其默认值为两分钟，而不是最常用的9分钟。
3.停止等待协****议
优点是简单，但是信道利用率太低了。解决方法是采用连续ARQ协议，发送方维持发送窗口，每次连续发送几个分组，接收方采用累积确认，对按序到达的最后一个分组发送确认。
缺点是不能向发送方反映出接收方已经正确收到的所有分组信息，例如丢失中间的分组。
4.TCP****可靠传输的实现
TCP 连接的每一端都必须设有两个窗口——一个发送窗口和一个接收窗口。TCP 的可靠传输机制用字节的序号进行控制。TCP 所有的确认都是基于序号而不是基于报文段。
发送过的数据未收到确认之前必须保留，以便超时重传时使用。发送窗口不动(没收到确认)和前移(收到新的确认)
发送缓存用来暂时存放： 发送应用程序传送给发送方 TCP 准备发送的数据；TCP 已发送出但尚未收到确认的数据。接收缓存用来暂时存放：按序到达的、但尚未被接收应用程序读取的数据； 不按序到达的数据。
必须强调三点：
1> A 的发送窗口并不总是和 B 的接收窗口一样大（因为有一定的时间滞后）。
2> TCP 标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。
3> TCP 要求接收方必须有累积确认的功能，这样可以减小传输开销
5.滑动窗口图解
TCP拥塞控制和流量控制的差别
拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能承受现有的网络负荷。
流量控制往往指的是点对点通信量的控制，是个端到端的问题。流量控制所要做的就是控制发送端发送数据的速率，以便使接收端来得及接受。
TCP流量控制
所谓的流量控制就是让发送方的发送速率不要太快，让接收方来得及接受。利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制。
TCP的窗口单位是字节，不是报文段，发送方的发送窗口不能超过接收方给出的接收窗口的数值。
只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器，若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。
TCP流量控制原理
所谓流量控制就是让发送发送速率不要过快，让接收方来得及接收。利用滑动窗口机制就可以实施流量控制。
原理这就是运用TCP报文段中的窗口大小字段来控制，发送方的发送窗口不可以大于接收方发回的窗口大小。
考虑一种特殊的情况，就是接收方若没有缓存足够使用，就会发送零窗口大小的报文，此时发送放将发送窗口设置为0，停止发送数据。之后接收方有足够的缓存，发送了非零窗口大小的报文，但是这个报文在中途丢失的，那么发送方的发送窗口就一直为零导致死锁。
解决这个问题，TCP为每一个连接设置一个持续计时器（persistence timer）。只要TCP的一方收到对方的零窗口通知，就启动该计时器，周期性的发送一个零窗口探测报文段。对方就在确认这个报文的时候给出现在的窗口大小（注意：TCP规定，即使设置为零窗口，也必须接收以下几种报文段：零窗口探测报文段、确认报文段和携带紧急数据的报文段）。
TCP拥塞控制
在某段时间，若对网络中的某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变化，这种情况叫做拥塞。
拥塞控制设计
拥塞控制是很难设计的，因为它是一个动态的问题，许多情况下，甚至正式拥塞控制机制本身成为引起网络性能恶化甚至死锁的原因。从控制理论的角度来看拥塞控制这个问题，可以分为开环控制和闭环控制两种方法。开环控制就是在设计网络时事先将有关拥塞发生的所有因素考虑周到，一旦系统运行起来就不能在中途改正。
闭环控制是基于反馈环路的概念，包括如下措施：
1）监测网路系统以便检测拥塞在何时何地发生
2）把拥塞发生的信息传送到可采取行动的地方
3）调整网络系统的行动以解决出现的问题。
拥塞控制方法
因特网建议标准RFC2581定义了进行拥塞控制的四种算法，即慢开始（****Slow-start)，拥塞避免（Congestion Avoidance)，快重传（Fast Restrangsmit)和快恢复（Fast Recovery）。我们假定
1）数据是单方向传送，而另外一个方向只传送确认。
2）接收方总是有足够大的缓存空间，因为发送窗口的大小由网络的拥塞程度来决定。
下图是慢启动和拥塞避免的一个可视化描述。我们以段为单位来显示cwnd和ssthresh，但它们实际上都是以字节为单位进行维护的。
TCP Tahoe版本已经废弃。
拥塞窗口概念
发送报文段速率的确定，既要根据接收端的接收能力，又要从全局考虑不要使网络发生拥塞，这由接收窗口和拥塞窗口两个状态量确定。接收端窗口（Reciver Window)又称通知窗口（Advertised Window),是接收端根据目前的接收缓存大小所许诺的最新窗口值，是来自接收端的流量控制。拥塞窗口****cwnd（Congestion Window)是发送端根据自己估计的网络拥塞程度而设置的窗口值，是来自发送端的流量控制。
（1）****慢启动原理
1）当主机开始发送数据时，如果立即将较大的发送窗口的全部数据字节都注入到网络中，那么由于不清楚网络的情况，有可能引其网络拥塞
2）比较好的方法是试探一下，即从小到达逐渐增大发送端的拥塞控制窗口数值
3）通常在刚刚开始发送报文段时可先将拥塞窗口cwnd(拥塞窗口)设置为一个最大报文段的MSS的数值。在每收到一个对新报文段确认后，将拥塞窗口增加至多一个MSS的数值，当rwind（接收窗口）足够大的时候，为了防止拥塞窗口cwind的增长引起网络拥塞，还需要另外一个变量---慢开始门限ssthresh
（2）拥塞控制
具体过程为：
1）TCP连接初始化，将拥塞窗口设置为1
2）执行 慢开始算法：cwind按指数规律增长，知道cwind == ssthress开始执行 拥塞避免算法：cwnd按线性规律增长
3）当网络发生拥塞，把ssthresh值更新为拥塞前ssthresh值的一半，cwnd重新设置为1，按照步骤（2）执行。
（3）快重传和快恢复
一条TCP连接有时会因等待重传计时器的超时而空闲较长的时间，慢开始和拥塞避免无法很好的解决这类问题，因此提出了快重传和快恢复的拥塞控制方法。
快重传算法并非取消了重传机制，只是在某些情况下更早的重传丢失的报文段（如果当发送端接收到三个重复的确认ACK时，则断定分组丢失，立即重传丢失的报文段，而不必等待重传计时器超时）。
例如：M1，M2，M3 -----> M1,M3,缺失M2，则接收方向发送方持续发送M2重复确认，当发送方收到M2的三次重复确认，则认为M2报文丢失，启动快重传机制，重传数据，其他数据发送数据放入队列，待快重传结束后再正常传输。
快恢复算法有以下两个要点：
1）当发送方连续收到接收方发来的三个重复确认时，就执行“乘法减小”算法，把慢开始门限减半，这是为了预防网络发生拥塞。
2）由于发送方现在认为网络很可能没有发生拥塞，因此现在不执行慢开始算法，而是把cwnd(拥塞窗口)值设置为慢开始门限减半后的值，然后开始执行拥塞避免算法，使拥塞窗口的线性增大。
备注：重传机制
超时重传是TCP协议保证数据可靠性的另一个重要机制，其原理是在发送某一个数据以后就开启一个计时器，在一定时间内如果没有得到发送的数据报的ACK报文，那么就重新发送数据，直到发送成功为止。
报文丢失重复确认情况
持续收到重复的ACK号，代表该报文丢失，触发快速重传机制
Seq：就是告诉接收方：我发送的数据是从seq开始的。
Ack：就是告诉接收方：我希望下次收到对端发过来的seq序号。
当重传主机从发送端接收到3个重复ACK时，它会假设此报文确实在传送中丢失，并且立即发送一个快速重传。一旦触发了快速重传，所有正在传输的其他报文都被放入队列中暂停发送，直到快速重传报文发送完为止。
过程如下图所示：
TCP三次握手，四次挥手
TCP标志位,有6种标示:
SYN(synchronous建立联机)
ACK(acknowledgement 确认)
PSH(push传送)
FIN(finish结束)
RST(reset重置)
URG(urgent紧急)
推荐
最后推荐一个不错的TCP/IP协议栈LwIP协议栈，可移植的协议栈
我的github上面有 源代码 ，地址：https://github.com/manmao/lwip_contrib.git
