零散的知识点：
网络层为主机之间提供逻辑通信，运输层为应用进程之间提供端到端的逻辑通信。
运输层向高层屏蔽了下层网络的核心细节，使得应用进程看起来好像是两个运输实体之间有一条端到端的逻辑通信道路。
当使用tcp协议的时候，逻辑通路就像一条全双工的可靠信道，而采用无连接的udp的时候就像一条不可靠的信道。
运输层主要采用两种的通信方式，一种是提供可靠传输的tcp协议，一种是提供不可靠传输的udp协议。
软件端口是应用层的各种协议进程与运输实体键兴层间交互的一种地址。
计算机中的端口分类：
计算机中的端口一般分为两种，
一种是服务端使用的端口，
服务端的端口也分为两小类，一类叫做熟知端口或者叫系统端口；0～1023
另一类叫做等级端口，使用这类端口需要进行登记，1024～49151
另一大类是客户端使用的端口，49152～65535，在客户端运行时才动态选择，也叫做短暂端口号。
各种应用和协议之间的关系：
tcp和udp的区别：
- tcp面向连接，udp非面向连接。 —–tcp提供面向连接的的服务，在进行报文交互传输前需要进行3次握手的连接建立，在数据交互完成需要进行4次挥手的断开连接。udp在传输udp用户数据报的时候不需要提前建立连接，采用直接发送的方式。
- tcp可靠的交付，udp不可靠的交付。 ——tcp提供重传和按序号传送的以及流量控制的功能，udp知识尽最大努力的交付。
- tcp拆分传输，udp整个传输。 —–tcp是面向字节流的，他把数据看作一连串无结构的字节流，他会对数据进行分拆包装。udp对应用层交付下来的报文不拆分也不组合，直接发送。一次发送一个报文。
- 通信方式不一样 — tcp支持的一对一的交流方式，udp支持一对一，一对多，多对多，多对一的交流方式。
- tcp有发送窗口等的机制，可以实现流量控制，而udp没有发送窗口的机制，它不能进行拥塞控制和流量控制。
- 检验方式不一样，udp计算检验和是把首部和数据部分一起检验，tcp只是检验IP数据报的首部。
udp的特点以及首部：
udp是无连接的，
尽最大的努力交付，没有重传和编序号的方式。
面向报文，对报不进行拆分组合，直接发送一整个报文。
udp支持一对一，一对多，多对一，多对多的传输方式。
udp的首部比tcp首部的20个字节要小，它只有8个字节。
udp的报文首部：
首部由8个字节四个部分组成，每个部分由2个字节。
1. 源端口：在需要交互方回信的时候选用，不需要回信使用0.
2. 目的端口：在终点交付报文的时候必须使用。
3. 长度：udp用户数据报的长度，最小为8.
4. 检验和：检测udp数据报在传输中是否有错误，有错就将其丢弃。（在计算检验和的时候，要在udp用户数据报之前添加12个字节的伪首部，伪首部既不下传递也不向上递交，作用仅为计算检验和）
tcp首部：
- 源端口和目的端口：各占两个字节。
- 序号：占4个字节。也叫报文段序号，tcp传输的每一个字节都按顺序编号。序号指的是本报文段发送的数据的第一个字节的序号。
- 确认号：占4个字节，表示期望收到对方下一个报文段的第一个数据字节的序号。（确认序号减去序号等于本段传输的报文的长度，确认号表示在这个序号的前一个数据之前的信息全部正确接收）
- 数据偏移：占4个字节，指出tcp报文段的数据起始处距离tcp报文段的起始有多远。
- 保留：占6个字节。
- 紧急urg，当urg = 1时，表明紧急指针有效，告诉系统这个报文段中有紧急数据，应当尽快传输。紧急数据插入本报文数据的最前面，紧急指针指出晋级数据的末尾在报文段中的位置。
- 确认ack，当ack = 1，确认号字段才有效。当ack = 0的时候确认号无效。tcp规定在建立连接之后所传诵的报文段都必须把ack置为1.
- 推送psh，接收方tcp收到psh = 1的报文段，就尽快交付给接收接收应用进程而不是再等到这个缓冲区都填满之后再向上交付。
- 复位rst，当rst = 1，标明tcp有严重的错误，必须释放连接，重新建立运输连接。rst = 1还可以用来拒绝一个非法的报文段或者拒绝打开一个连接。
- 同步syn，当syn = 1， ack = 0，标明这是一个连接请求报文段，对方如果同意建立连接，在响应报文段中syn = 1， ack = 1.
- 终止fin， 释放一个连接，fin = 1， 表示报文段的发送方的数据已经发送完成，请求释放连接。
- 窗口：占2个字节，存放的是数据是字节为单位的窗口值告诉对方，本报文段首部中的确认号算起，接收方目前允许对方发送的数据量。这是让发送方设置发送窗口的依据。
- 检验和，占2个字节。
tcp的可靠原理：
1、停止等待协议：
发送方发送之后等待接受方的确认报文，再继续发送，如果发送丢失或者确认报文丢失，超时计时器到期，进行超时重传。如果编号不对，也会进行重传的活动。
（使用确认和重传机制，我们可以在不可靠的的传输网络上进行可靠传输）
2、连续arq协议：
使用了滑动窗口的机制。
累积确认的方式，对按序到达的一个分组发送确认。如果分组的数据段丢失只会确认前面连续成功接收的。
3、流量控制：发送方不要太快，让接受方来得及接收。（利用滑动窗口机制实现对发送方的流量控制）
接收方额主机进行了三次流量控制，而且ACK = 1时确认字段才有意义。
问题出现：当接收方有空间可以接受发送方的数据的时候，接收方向发送方发送包含rwnd的报文段，然而这个报文如果丢失，发送方将一直等待接收方的通知报文，而接收方却一直以为发送方接收到了，这个时候接收方将进入一个等待的状态。这就成了一个死循环，双方都在等待。
解决方案：
tcp为每个连接设有一个持续计时器，只要tcp连接的一方收到了对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口探测报文段，而对方就在确认这个探测报文段时给出了现在的窗口值。如果窗口任然是零，那么收到这个报文段的一方就重新设置持续计时器。如果窗口不是零，那么死锁的僵局就可以打破
tcp报文的发送时机：
- 定制最大报文段长度MSS，只要缓冲中存放的数据达到MSS字节，组装成一个tcp报文段发送。
- 发送方进程设置了psh字段，指明不等待缓冲区满。（或者是urg的紧急字段）
- 发送方计时器期限到了，把当前已有的缓冲数据装入报文段发送出去。
注意：在tcp的传送中，流量控制通过接收方的接收窗口(rwnd)实现的，拥塞控制通过发送方的拥塞窗口(cwnd)实现的。
TCP的拥塞控制
1. 基本概念：
拥塞：即对资源的需求超过了可用的资源。若网络中许多资源同时供应不足，网络的性能就要明显变坏，整个网络的吞吐量随之负荷的增大而下降。
拥塞控制：防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提：网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机、路由器，以及与降低网络传输性能有关的所有因素。
流量控制：指点对点通信量的控制，是端到端正的问题。流量控制所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。
拥塞控制代价：需要获得网络内部流量分布的信息。在实施拥塞控制之前，还需要在结点之间交换信息和各种命令，以便选择控制的策略和实施控制。这样就产生了额外的开销。拥塞控制还需要将一些资源分配给各个用户单独使用，使得网络资源不能更好地实现共享。
2、拥塞控制办法：
慢启动、拥塞避免、快速重传和快速恢复。
2.1 慢启动和拥塞避免
发送方维持一个拥塞窗口cwnd的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞。
发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减少一些，以减少注入到网络中的分组数。
慢启动算法：当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么就有可能引起网络拥塞，因为现在并不清楚网络的负荷情况。因此，较好的办法是先探测下，即由小到大逐渐增大发送窗口，也就说，由小到大逐渐增大拥塞窗口数值。通常在刚刚开始发送报文段时，先把拥塞窗口cwnd设置为一个最大报文段MSS的数值。而在每收到一个对新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值。用这样的方法逐步增大发送方的拥塞窗口cwnd，可以使分组注入到网络的速率更加合理。
每经过一个传输轮次，拥塞窗口wcnd就加倍。一个传输轮次所经历的时间其实就是往返时间RTT。不过，“传输轮次”更加强调：把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并收到了对已经发送的最后一个字节的确认。
另外，慢启动的“慢”并不是指cwnd的增长速度慢，而是指在TCP开始发送报文段时先设置cwnd=1，使得发送方在开始时只发送一个报文段（目的是探测一下网络的拥塞情况），然后再逐渐增大cwnd。
为了防止拥塞窗口cwnd增长过大而引起网络拥塞，还需要设置一个慢启动门限ssthresh状态变量（如何设置ssthresh）。慢启动门限ssthresh的用法如下：
当cwnd < ssthresh时，使用上述的慢启动算法；
当cwnd > ssthresh时，停止使用慢启动算法而改用拥塞避免算法；
当cwnd = ssthresh时，即可使用慢启动算法，也可以使用拥塞避免算法；
拥塞避免算法：让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。
无论慢启动开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认），就要把慢启动门限ssthresh设置为出现拥塞时的发送方窗口值的一半（但不能小于2）。然后把拥塞窗口cwnd重新设置为1，执行慢启动算法。这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。
拥塞控制例子：
用具体数值说明了上述拥塞控制的过程。现在发送窗口的大小和拥塞窗口一样大。
当TCP连接进行初始化时，把拥塞窗口cwnd置为1。前面已说过，为了便于理解，图中的窗口单位不使用字节而使用报文段的个数。慢开始门限的初始值设置为16个报文段，即 cwnd = 16 。
在执行慢开始算法时，拥塞窗口 cwnd 的初始值为1。以后发送方每收到一个对新报文段的确认ACK，就把拥塞窗口值另1，然后开始下一轮的传输（图中横坐标为传输轮次）。因此拥塞窗口cwnd随着传输轮次按指数规律增长。当拥塞窗口cwnd增长到慢开始门限值ssthresh时（即当cwnd=16时），就改为执行拥塞控制算法，拥塞窗口按线性规律增长。
假定拥塞窗口的数值增长到24时，网络出现超时（这很可能就是网络发生拥塞了）。更新后的ssthresh值变为12（即变为出现超时时的拥塞窗口数值24的一半），拥塞窗口再重新设置为1，并执行慢开始算法。当cwnd=ssthresh=12时改为执行拥塞避免算法，拥塞窗口按线性规律增长，每经过一个往返时间增加一个MSS的大小。
强调：“拥塞避免”并非指完全能够避免了拥塞。利用以上的措施要完全避免网络拥塞还是不可能的。“拥塞避免”是说在拥塞避免阶段将拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞。
2.2 快速重传和快速恢复
如果发送方设置了超时计时器时限已到但还没有收到确认，那么很可能是网络出现了拥塞，致使报文段在网络中的某处被丢弃。这时，TCP马上把拥塞窗口cwnd减少到1，并执行慢启动算法，同时把慢启动门限值ssthresh减半。这是不使用快速重传的情况。
快速重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有达到对方）而不要等到自己发送数据时才进行捎带确认。
接收方收到了M1和M2后都分别发出了确认。现在假定接收方没有收到M3但接着收到了M4。显然，接收方不能确认M4，因为M4是收到的失序报文段。根据可靠传输原理，接收方可以什么都不做，也可以在适当时机发送一次对M2的确认。但按照快重传算法的规定，接收方应及时发送对M2的重复确认，这样做可以让发送方及早知道报文段M3没有到达接收方。发送方接着发送了M5和M6。接收方收到这两个报文后，也还要再次发出对M2的重复确认。这样，发送方共收到了接收方的四个对M2的确认，其中后三个都是重复确认。快重传算法还规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段M3，而不必继续等待M3设置的重传计时器到期。由于发送方尽早重传未被确认的报文段，因此采用快重传后可以使整个网络吞吐量提高约20%。
与快重传配合使用的还有快恢复算法，其过程有以下两个要点：
<1>. 当发送方连续收到三个重复确认，就执行“乘法减小”算法，把慢开始门限ssthresh减半。这是为了 预防网络发生拥塞。请注意：接下去不执行慢开始算法。
<2>. 由于发送方现在认为网络很可能没有发生拥塞，因此与慢开始不同之处是现在不执行慢开始算法（即拥塞窗口cwnd现在不设置为1），而是把cwnd值设置为慢开始门限ssthresh减半后的数值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大。
下图给出了快重传和快恢复的示意图，并标明了“TCP Reno版本”。
区别：新的 TCP Reno 版本在快重传之后采用快恢复算法而不是采用慢开始算法。
也有的快重传实现是把开始时的拥塞窗口cwnd值再增大一点，即等于 ssthresh + 3 X MSS 。这样做的理由是：既然发送方收到三个重复的确认，就表明有三个分组已经离开了网络。这三个分组不再消耗网络 的资源而是停留在接收方的缓存中。可见现在网络中并不是堆积了分组而是减少了三个分组。因此可以适当把拥塞窗口扩大了些。
在采用快恢复算法时，慢开始算法只是在TCP连接建立时和网络出现超时时才使用。
采用这样的拥塞控制方法使得TCP的性能有明显的改进。
接收方根据自己的接收能力设定了接收窗口rwnd，并把这个窗口值写入TCP首部中的窗口字段，传送给发送方。因此，接收窗口又称为通知窗口。因此，从接收方对发送方的流量控制的角度考虑，发送方的发送窗口一定不能超过对方给出的接收窗口rwnd 。
发送方窗口的上限值 = Min [ rwnd, cwnd ]
当rwnd < cwnd 时，是接收方的接收能力限制发送方窗口的最大值。
当cwnd < rwnd 时，则是网络的拥塞限制发送方窗口的最大值。
tcp连接：
运输的三个阶段：连接建立、数据传送、连接释放
tcp的连接采用客户服务器的方式：主动发起连接的进程叫做客户，被动等待连接的叫做服务器。
服务端的进程首先创建传输控制块TCB，然后处于等待的状态监听。
客户端进程首先创建传输控制块TCB，向服务器发送请求报文。
第三次的确认是为了防止失效的请求报文又传到服务器。
tcp释放：
all