运输层
主要内容：进程的通信，UDP协议，TCP协议，可靠传输工作原理（停止等待协议和ARQ协议），TCP的滑动窗口，流量控制，和拥塞控制。
一：进程的通信
（1） 运输层是向最上面的应用层提供通信服务，属于面向通信部分的最高层，也是用户功能的最底层。
（2） 通信的实体：IP层的角度来说通信的实体是两台主机，在运输层，通信的实体是主机之间的进程的通信，IP协议是数据传送到主机，其实通信的终点在主机中的进程。
（3） 复用和分用：复用值得是发送方所有的应用进程都可以使用同一个运输层协议传送数据，分用是接收方，在去首部之后，能把数据正确的交付到目的进程。
（4） 可靠传输：网络层检错只是对首部进行检错，运输层要对收到的报文进行检测，当运输层使用面向连接的TCP协议的时候，尽管下面的网络是不可靠的，但是逻辑通信就相当于一条全双工的可靠通信。（当使用UDP协议仍然是不可靠信道）
（5） 协议：TCP/IP体系中，根据使用的协议是TCP/UDP，分别为TCP报文段，活UDP用户数据报。TCP提供面向连接的服务：传送数据之前必须建立连接，数据结束之后要释放连接（http：1.1好像可以保持持久连接）UDP:在传送数据之前不需要建立连接，在传送数据的时候，目的主机在收到UDP报文的时候不需要给出任何确认。
（6） 常见的使用UDP和TCP的各种应用层协议：DNS,RIP,DHCP,NFS（UDP协议）
TCP协议（TELNET,HTTP,FTP）；
（7） 端口：端口是标识本地计算机应用层中的各个进程和运输层交互的层间接口。
常见使用的端口：HTPP 80 HTTPS 443 DNS 53 FTP 21
(二)UDP协议
（1）UDO主要特点： ①DUP是无连接（发送数据之前不需要建立连接,结束也不需要释放连接），减少开销和发送数据之前的延迟。②UDP尽最大努力交付，不可靠交付，所以不需要维持复杂的连接状态。③UDP是面向报文，对于应用程序交下来的报文，在添加首部后就向下交付IP层。④UDP没有拥塞控制，因此网络出现的拥塞不会让源主机发送的速率降低。对于实时的应用很重要（IP电话，实时视频），如果使用TCP传送，在网络通信量大的时候，电话信息无法发送等等问题，使用UDP就可以不用担心传输的问题。⑤UDP支持一对一，一对多，多对一，多对多的通信。⑥UDP首部开销比小，只有8个字节，比TCP的20个字节的首部要短。
（2）UDP首部格式：
①源端口 //用于接收方回信
②目的端口//终点报文交付
③长度UDP数据报长度，最小8个字节（只有首部）
④检验和：用来检测UDP数据报，在传输是否有错，如果有错就丢弃。
（三）TCP协议
（1）TCP协议的特点：
①TCP是面向连接的运输层协议。
②TCP连接只能有两个端点，也就是每一条TCP连接只能是点对点的（一对一的）。③TCP可靠交付的服务，通过TCP连接传送的数据，无差错，不丢失，不重复，并且按序到达。
④TCP提供全双工通信，TCP循序通信双方的应用进程在任何时候都能发送数据。TCP连接的两端设有发送缓存和接收缓存，用来临时存放双向通信的数据。
⑤面向字节流。应用程序和TCP的交互式一次一个数据块，但是TCP把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。
流指的是流入到进程或者从进程流出的字节序列。
（2）TCP连接的端点叫做套接字或者插口。
套接字 socket = (IP地址,端口号);
TCP连接::= {socket1,socket2}} = {(IP1:PORT1),(IP2:PORT2)}
（3）可靠传输
理想的传输条件：
①传输信道不产生差错
②不管发送方以多块的速度来发送数据，接收方总是来得及处理收到的数据。
可靠传输协议的实现：当出现误差的时候，让发送方重传（发送方需要对发送的数据备份，在接收方确认之后才能丢弃），在接收方来不及处理接收到的数据时，适当降低发送速率。
（4） A（发送方），B（接收方）， M1（发送报文），M1（确认M1）
停止等待协议：简单理解就是每次发完一个分组就停止发送，等待对方的确认，在收到确认后再发送下一个分组。
出现差错：超时重传，发送方在超过一段时候只会仍然没有收到确认，就人为刚发送的分组丢失了，就要重传，这里需要一个超时定时器。接收方接收到错误的信息的时候直接丢弃。//在这是接收方直接丢弃错误的报文下，当发送方报文，由于网络原因丢失同样可以超时重传。
确认丢失和确认迟到：（B发送M1确认报文丢失，A在超时重传中没有收到确认，无法知道是自己发送的分组出错还是丢失，或者B发送的确认丢失了）条件，B收到了重传的分组M1，应该采取两个行动。
第一：丢弃这个分组，不交付给上层。
第二：向A发送确认。
对于重复的确认，收下就丢弃，B仍然会受到重复的M1，并且要丢弃M1，并重新确认分组。
自动重传请求ARQ：重传的请求是自动进行的，接收方不需要请求发送方重传某个出错的分组。
（5）连续ARQ协议和滑动窗口协议。
连续AQR就是每次发送多个多个分组，接收方采取累积确认的方式，接收方不必对收到的分组逐个发送确认，而是收到几个分组后，对按序到达的最后一个分组进行发送确认。发送方每次收到一个确认就把发送窗口向前滑动一个分组的位置，如果发送方发送了前5个分组，而中间的三个分组丢失了，这时接收方只需要对前两个分组发出确认。
（6）TCP报文段的首部格式
（1）源端口和目的端口 //与UDP一样各占2个字节
（2）序号占4个字节 TCP连接中的每一个字节都按照顺序编号，首部中的序列字段是本报文段所发送的数据的第一个字节的序号。
（3）确认号4个字节，是期望收到对方下一个报文段的第一个数据字节的序号。确认号=N，表示N-1为止的所有数据都已经收到。
（4）数据偏移 4个字节，指出TCP报文段的数据其实去距离TCP报文段的起始处有又多远。实际代表是TCP首部长度。
（5）保留 6位。今后使用，但目前应该置为0；
（6）紧急URG //当URG = 1 表示紧急指针字段有效，告诉系统此报文段中有紧急数据，应尽快传送（相当于高优先级的数据）
（7）确认ACK，ACK=1 确认号字段才有效，TCP在建立连接之后所有传送的报文段都必须把ACK置1；//很重要后面TCP三次握手
（8）推送PSH，当两个应用进程进行交互的通信时，有时在一端的应用进程希网在键入一个命令就能接受对方的响应，TCP可以使用推送操作。
（9）复位RST 当RST = 1 是说明TCP连接出现严重差错必须释放连接在重新建立连接。
（10）同步SYN，在建立连接时的同步序号，当SYN=1且ACK=0时，表明这是一个连接请求报文段。对方同意建立连接，则应在响应的报文段中使SYN=1和 ACK=1.
（11）终止FIN，用来释放一个连接，当FIN=1时，表明此报文段的发送方的数据已经发送完毕，并要求释放运输连接。
（12）窗口 2个字节，窗口值是【0, -1】之间的连接。窗口是用来控制接收的数量，现在允许对方发送的数据量，窗口值一直在动态变换着。//滑动窗口
例如：发送了一个报文段，确认号是701，窗口字段是1000，告诉对方，从701开始算起，我的接收方的接收缓存还可以接收1000个字节的数据（字节序列号应该是701-1700）。
（13）检验和占2个字节，跟UDP类似，检查首部和数据部分。
（14）紧急指针占2个字节。
（15）选项，长度可变，最长可达40字节，当没有选项的时候，TCP的首部长度是20字节。
（7）TCP可靠传输的实现 假设A发送数据，B给出确认。（A的发送窗口和B的接收窗口）
①字节为单位的滑动窗口（滑动窗口机制是TCP协议的一种流量控制和防拥塞的机制。）
A的发送窗口：在没有收到B的确认的情况下，A可以联系把窗口内的数据都发送出去。，但是凡事发送出去的数据，在收到确认之前都必须暂时保留，以便超时重传。
滑动窗口的是随时变化的：在没有收到新的确认对方通知的窗口大小也不变，窗口不发生变化，收到新的确认倒是对方通知的窗口缩小了，这样使得窗口前沿正好不动。
发送缓存：（1）发送缓存是发送应用程序传送给发送方TCP准备发送的数据。
（2）TCP已经发送暗示尚未收到确认的数据
接收缓存：（1）按序到达，但是尚未被应用程序读取的数据
（2）未按序到达的数据
②选择确认SACK：若收到的报文段没差错，只是未按序号中间还缺少一些数据，设法只是重传缺少的数据，而不是重传已经正确到达接收方的数据。(但是如果要使用选择确认SACK)，我们在建立TCP连接的时候，首部加上“允许SACK”的选项。（但是大多数还是重传所有未被确认的数据块）。
（7）TCP的流量控制
流量控制：让发送方的发送数据的速率不要太快，要让接收方来得及接收。
A-》B发送数据，在建立连接的时候，B告诉了A：我接收窗口 rwnd = 400，发送方的发送窗口不能超过接收方给出的接收窗口的数值。
（8） TCP的拥塞控制
拥塞：若对网络中某一资源的需求超过了该资源所能提空的可用部分，网络的性能就要变坏。
拥塞控制：放置过多的数据注入网络中路由器或链路不致过载。拥塞控制是是个全局的过程。
流量控制：是点对点通信量的控制，是一个端到端的控制，一直发送端发送数据的速率，以便使接收端来得及接收。
（9） TCP拥塞控制的方法
① 慢开始②拥塞避免③快重传④快恢复
拥塞控制：基于窗口的拥塞控制，发送方维持一个叫做拥塞窗口cwnd。发送方让自己的发送窗口等于拥塞窗口。
慢开始：在开始发送数据的时候，由于不清楚网络的负荷情况，由小到大逐渐增加拥塞窗口的数值。为了防止拥塞窗口cwnd增长过快引起网络拥堵，还要设置一个快开始门限状态变量，ssthresh(快开始门限)
慢开始门限：
当cwnd<ssthresh时，使用上述的慢开始算法。
当cwnd>ssthresh时，停止使用慢开始算法而改用拥塞避免算法。
当cwnd=ssthersh时，既可以使用慢开始算法，也可以改用拥塞避免算法。
拥塞避免算法：让拥塞窗口cwnd缓慢的增大，每次经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1。
慢开始：开始试探缓慢开始指数增长。
快重传算法：让发送方尽量知道发生了个别报文段的丢失，快重传算法首先要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认。（接收方收到了M1和M2后都分别及时发出了确认，假设接收方没有收到M3但是却收到了M4，本来接收方可以什么都不做，但按照快重传算法，必须立即发送对M2的重复确认，让发送方知道接收方没有收到M3，发送方一连收到3个重复确认，就知道接收方确实没有收到，应该立刻重传）
快恢复；在发送方知道现在只是丢失了个别的符文段，于是不启动慢开始，而是执行快恢复算法。不把窗口置为1，置为当前ssthersh的一半。
发送方窗口的上限值 = Min[rwnd,cwnd];
Rwnd = 接受窗口 cwnd = 拥塞窗口
（10） TCP的运输连接管理（三次握手，四次挥手）
运输连接三个阶段：连接建立，数据传送，连接释放。
TCP连接的过程叫做握手，握手需要客户和服务器之间交换三个TCP报文。
第一次握手：建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。
为什么要三次挥手？
在只有两次“握手”的情形下，假设Client想跟Server建立连接，但是却因为中途连接请求的数据报丢失了，故Client端不得不重新发送一遍；这个时候Server端仅收到一个连接请求，因此可以正常的建立连接。但是，有时候Client端重新发送请求不是因为数据报丢失了，而是有可能数据传输过程因为网络并发量很大在某结点被阻塞了，这种情形下Server端将先后收到2次请求，并持续等待两个Client请求向他发送数据...问题就在这里，Cient端实际上只有一次请求，而Server端却有2个响应，极端的情况可能由于Client端多次重新发送请求数据而导致Server端最后建立了N多个响应在等待，因而造成极大的资源浪费！所以，“三次握手”很有必要！
为什么要四次挥手？
试想一下，假如现在你是客户端你想断开跟Server的所有连接该怎么做？第一步，你自己先停止向Server端发送数据，并等待Server的回复。但事情还没有完，虽然你自身不往Server发送数据了，但是因为你们之前已经建立好平等的连接了，所以此时他也有主动权向你发送数据；故Server端还得终止主动向你发送数据，并等待你的确认。其实，说白了就是保证双方的一个合约的完整执行！