计算机网络---传输层

传输层概述

描述

只有主机才有的层次（在传输过程中经过的路由器、交换机都是没有这个层次的，最多知道网络层）

功能

1.传输层提供进程和进程之间的通信（网络层只负责把数据在主机之间进行通信，而这个数据往往是某个具体的进程的，传输层就是这个）
2.复用和分用（复用：传输不同进程之间的数据用的是同一个协议；分用：对传输的数据给到正确的进程）
3.传输层对收到的报文进行差错检测（在前面三层，他只是负责对报文的头部文件进行检测，而这要对数据进行检测）

传输层的两个协议

TCP和UDP

面向连接的传输控制协议TCP	无连接的用户数据报协议UDP
传送数据之前必须建立连接，数据传送结束后要释放连接。不提供广播或多播服务。由于TCP要提供可靠的面向连接的传输服务，因此不可避免增加了许多开销:确认、流量控制、计时器及连接管理等。	传送数据之前不需要建立连接，收到UDP报文后也不需要给出任何确认。
可靠，面向连接，时延大，适用与大文件	不可靠，无连接，时延小，适用于小文件

传输层的寻址与端口

复用:应用层所有的应用进程都可以通过传输层再传输到网络层。
分用:传输层从网络层收到数据后交付指明的应用进程。

（端口是逻辑端口、软件端口，是传输层的SAP，表示主机中的应用进程）

端口号只有本地意义（只在自己电脑中有意义），在因特网中不同计算机的相同端口是没有联系的

端口号长度为16bit，能表示65536个不同的端口号。

端口号分类如上图所示

服务端使用的端口号其实就是服务器使用的端口，而客户端使用的端口号其实就是我们自己的电脑使用的端口号（这个稍稍需要思考一下，但是理解还是很直白的）

而熟知端口号就是图中的解释（用来给一些固定的服务程序的端口）

登记端口号就是没有固定端口的，但是还是服务器的

客户端的就直接动态分配，用完给另一个人用

常用的进程的端口号

下面那行就是用来记忆的

（虽然觉得很傻，但是还是打上来，万一有人喜欢呢）

21岁发现F一女孩（所以是FTP）

23岁和这个女孩谈恋爱T（所以是TELNET）

25岁谈崩了，删S了好友（所以是SMTP）

53岁后悔了，怀念青春给他打D电话（所以是DNS）

80岁还H想要再见一面（所以是HTTP）

在网络中采用发送方和接收方的套接字组合来识别端点，套接字唯一标识了网络中的一个主机和它上面的一个进程。（套件字Socket=（主机IP地址，端口号））

UDP协议

UDP只是在IP数据报服务之上增加了很少功能，即复用分用和差错检测功能

UDP的主要特点

1.UDP是无连接的，减少开销和发送数据之前的时延。（这个很好理解，不用搭钱直接给，减少消耗）
2.UDP使用最大努力交付，即不保证可靠交付。（就是不保证你一定的收到，只保证我一定发出去）
3.UDP是面向报文的，适合一次性传输少量数据的网络应用（因为UDP直接把所有报文内容装进去，不会进行分片，因此不适合大量内容）

4.UDP无拥塞控制，适合很多实时应用（这个就是，我传归我传，收不到是你网不好，和我没关系）
5.UDP首部开销小，8B，TCP首部20B（字面意思奥）

UDP首部格式

16位源端口号：源端口号嘛，就是标明那个进程出来的（可有可无，要收确认帧的就得有，不用的爱有没有，没有全0）

16目的端口号：目的端口嘛，就是标明你要发给谁（这个必须有，没有目的地，你这数据发出去干啥，喝西北风吗）

16位UDP长度：用来记录整个UDP的长度（比如数据长7B，那么UDP长度=15，因为还有首部的8B）

16位UDP检验和：检测整个UDP数据报是否有错，错就丢弃（这里是整个奥，因为传输层还要对数据进行检测）

当然，还有一种错误：
分用时，找不到对应的目的端口号，就丢弃报文，并给发送方发送ICMP“端口不可达”差错报告报文。

UDP校验

在UDP校验的时候会出现一个伪首部（这个玩意儿不向上递交，也不向下传递）

具体形式如上图所示

伪首部会有源IP地址（4B）、目的IP地址（4B）、固定全0（1B）、协议代号（1B）、UDP长度（2B，这个就是首部有过，但我不知道为什么还要再来一次）

在发送端:
1.填上伪首部
2.全0填充检验和字段
3.全0填充数据部分(UDP数据报要看成许多4B的字串接起来)
4.伪首部+首部+数据部分采用二
进制反码求和
5.把和求反码填入检验和字段
6.去掉伪首部，发送

在接收端:
1.填上伪首部
2.伪首部+首部+数据部分采用二
进制反码求和
3.结果全为1则无差错，否则丢弃数据报/交给应用层附上出差错的警告。
（注：这次为什么是全1呢，因为第二部分中的检验和字段已经不是全0了，是在发送端获得的检验和）

检验和的求法：二进制反码运算求和（这是个什么玩意儿呢，就是0+0=0，但是进位；0+1=1,1+1=0）

至于这么多行怎么算呢，对不起只能两两相加求，最后还要记得求反码，下面给出一张过程图，自己体会（图中右边是十六进制的计算方式，具体方法看下）

在十六进制版中，运算最会大大减小，主要的计算步骤如下:
(1)从右边第-列开始，按照十进制来计算第一列的值。
在这里第一列算出来是107, 写成8位二进制就是01101011。

(2)根据算出来的结果分成两部分，左边的4位化成十进制，作为下一列进位时加的数,右边4位
化成16进制，作为第一列的结果。
这里就是610B16，图片误算成D，6作为下一列运算时要加上的对象，B作为第一列的结果。

(3)十进制计算第一列的结果，加上第-列得到的进位得到第二列的一个十进制数字,化为二进制，根据第二步来进行判断，依次类推。
在这里第二列算到的是24,加上6就是30,化为8位二进制就是00011110，也就是1E，第二列的结果为1，第三列的十进制进位为1。接着可以算到第三列的结果为6，十进制进位为4。

(4)最高位算出最后的十进制结果后,化为1进制时，右边4位作为最终结果,左边4位移入下一列，用上-步得到的结果96EB,加上0010,得到最后结果，这里图片的最后一步写错了，不应该舍弃。
最后能得到结果为96ED.
(5)结果取反,得到校验码。
校验码为6912。

TCP协议

特点

1.TCP是面向连接(虚连接)的传输层协议。（逻辑上的进程对进程，没有实际的点对点链路）

2.每一条TCP连接只能有两个端点，每一条TCP连接只能是点对点的。

3.TCP提供可靠交付的服务，无差错、不丢失、不重复、按序到达。

4.TCP提供全双工通信。（发送缓存 准备发送的数据&已发送但尚未收到确认的数据；接收缓存按序到达但尚未被接受应用程序读取的数据&不按序到达的数据）

5.TCP面向字节流—TCP把应用程序交 下来的数据看成仅仅是一连串的无结构的字节流。（就是不管你来的是什么，反正都是二进制，只管这个东西）

TCP报文段首部格式

源端口（2B）：这个老客户了

目的端口（2B）：这个也是奥

序号（4B）：在一个TCP连接中传送的字节流中的每一个字节都按顺序编号，本字段表示本报文段所发送数据的第一个字节的序号。（就是数据段的第一个字节在原来数据的位置）

确认号（4B）：期望收到对方下一个报文段的第一个数据字节的序号。若确认号为N,则证明到序号N-1为止的所有数据都已正确收到。（一看就是老确认帧了，并且数是最后一个字节在原数据的位置+1）

数据偏移（首部长度，1B）：TCP报文段的数据起始处距离TCP报文段的起始处有多远，以4B位单位，即1个数值是4B。（字面意思，表示TCP的首部长度，例如：1111，就是表示TCP首部长度是60B=15*4+20）

6个控制位（所以有2b的保留）：

紧急位URG: URG=1时， 标明此报文段中有紧急数据，是高优先级的数据，应尽快传送，不用在缓存里排队，配合紧急指针字段使用。（这个就是已放入缓存，虽然在最后，但是会直接发送）

确认位ACK: ACK=1时确认号有效，在连接建立后所有传送的报文段都必须把ACK置为1。（这个就是字面意思奥）

推送位PSH: PSH=1时， 接收方尽快交付接收应用进程，不再等到缓存填满再向上交付。（这个是给接收方用的，一收到这个帧，不管是不是全收到了，都要往上递交，不怎么考）

复位RST: RST=1时， 表明TCP连接中出现严重差错，必须释放连接，然后再重新建立传输链接。（这个就是字面意思了，也不怎么考）

同步位SYN: SYN=1时， 表明是一一个连接
请求/连接接受报文。（用来请求建立和接受建立连接）

终止位FIN: FIN=1时， 表明此报文段发送方数据已发完，要求释放连接。（这个也是字面意思奥）

窗口（2B）：指的是发送本报文段的一方的接收窗口，即现在允许对方发送的数据量。（用来返回确认帧的时候告诉发送方自己当前的接受窗口是多大，不要发太多）

检验和（4B）：检验首部+数据，检验时要加上12B伪首部，第四个字段为6（这个6是TCP协议的代号）

紧急指针：URG=1时才有意义，指出本报文段中紧急数据的字节数（表明数据中前多少的字节是紧急数据）

选项（不定长）：用来增加需要的东西（最大报文段长度MSS、窗口扩大、时间戳、选择确认）

填充（不定长）：用来把选项填充到4B的整数倍

TCP连接管理

TCP连接传输三个阶段：

TCP连接的建立采用客户服务器方式，主动发起建立的应用进程叫做客户，而被动等待连接建立的应用进程叫服务器（类似于打电话，拨打过去的叫做客户，点接听的叫服务器）

经典三次握手（用于建立）

步骤：
假设运行在一台主机(客户)上的一个进程想与另一台主机(服务器)上的一个进程建立一条连接，客户应用进程首先通知客户TCP，他想建立一个与服务器上某个进程之间的连接，客户中的TCP会用以下步骤与服务器中的TCP建立一条TCP连接:

ROUND 1:
客户端发送连接请求报文段，无应用层数据。
SYN=1，seq=x(随机)

ROUND 2:
服务器端为该TCP连接分配缓存和变量，并向客户端返回确认报文段，允许连接，无应用层数据。
SYN=1，ACK=1， seq=y(随机)， ack=x+1（这个ack表示可以送x之后的数据了）

ROUND 3:
客户端为该TCP连接分配缓存和变量，并向服务器端返回确认的确认，可以携带数据。
SYN=0，ACK=1, seq=x+1, ack=y+1（这个ack表示可以送y之后的数据了）

这就会导致被SYN洪泛攻击：
SYN洪泛攻击发生在OSI第四层，这种方式利用TCP协议的特性，就是三次握手。攻击者发送TCP SYN, SYN是TCP三次握手中的第一一个数据包，而当服务器返回ACK后，该攻击者就不对其进行再确认，那这个TCP连接就处于挂起状态，也就是所谓的半连接状态，服务器收不到再确认的话，还会重复发送ACK给攻击者。这样更加会浪费服务器的资源。攻击者就对服务器发送非常大量的这种TCP连接，由于每一个都没法完成三次握手，所以在服务器上，这些TCP连接会因为挂起状态而消耗CPU和内存，最后服务器可能死机，就无法为正常用户提供服务了。

解决方法：SYN Cookie（小拓展，不讲）

经典四次握手（用于释放连接）

参与一条TCP连接的两个进程中的任何一个都能终止该连接，连接结束后，主机中的“资源”(缓存和变量) 将被释放。

步骤：

ROUND 1:
客户端发送连接释放报文段，停止发送数据，主动关闭TCP连接。
FIN=1，seq=u（这个u就是送过去之后的位置）

ROUND 2:
服务器端回送一个确认报文段，客户到服务器这个方向的连接就释放了------半关闭状态。
ACK=1，seq=v， ack=u+1（这个v也是，送过去之后的位置）

ROUND 3:
服务器端发完数据，就发出连接释放报文段，主动
关闭TCP连接。
FIN=1，ACK=1， seq=w， ack=u+1

ROUND 4:
客户端回送一一个确认报文段， 再等到时间等待计时器设置的2MSL (最长报文段寿命)后，连接彻底关闭。
ACK=1，seq=u+1， ack=w+1（等到两边都关了以后还得送回去一个确认帧，所以有第四次）

TCP可靠传输

这个可靠传输是指：保证接收方进程从缓存区读出的字节流与发送方发出的字节流是完全一样的。

实现的方式有四种：
校验、序号、确认和重传

校验

这个和UDP的方式一样，都是采用二进制反码运算求和

序号、确认

这两个东西非常密切

序号和确认其实就是首部中的序号和确认

但是这里有一个机制，就是如果收到了后面的7、8数据报，但是没有收到4、5、6数据报，他就会在返回的ACK的首部中确认是4

这样发送端就会重传4、5、6及后面的报文

重传

超时重传：TCP的发送方在规定的时间内没有收到确认就要重传已发送的报文段。（这个规定的时间TCP采用自适应算法，动态改变重传时间RTTS，即加权平均往返时间，至于加权平均是啥建议自行百度，或者全当了解）

冗余ACK（冗余确认）
每当比期望序号大的失序报文段到达时，发送一个冗余ACK，指明下一个期待字节的序号。

发送方已发送1，2, 3, 4, 5报文段
接收方收到1，返回给1的确认(确认号为2的第一个字节)
接收方收到3，仍返回给1的确认(确认号为2的第一个字节)
接收方收到4，仍返回给1的确认(确认号为2的第一个字节)
接收方收到5，仍返回给1的确认(确认号为2的第一个字节)

发送方收到3个对于报文段1的冗余ACK，这样发送端就会认为2报文段丢失， 重传2号报文段（这个叫做快速重传）

TCP流量控制

流量控制:让发送方慢点，要让接收方来得及接收。

（PS：放上这张图的原因是我觉得这个表情包实在是太适合接收方给发送方了，慢点，我不行了）

TCP利用滑动窗口机制实现流量控制

在通信过程中，接收方根据自已接收缓存的大小，动态地调整发送方的发送窗口大小，即接收窗口rwnd (接收方设置确认报文段的窗口字段来将rwnd通知给发送方)，发送方的发送窗口取接收窗口rwnd和拥塞窗口cwnd的最小值（即min（rwnd，cwnd））

具体过程描述：
A向B发送数据，连接建立时，B告诉A:“ 我的rwnd=400 (字节)”，设每一个报文段100B，报文段序号初始值为1。

简单描述一下：
第一阶段
主机A窗口为400B，接连发了3个报文段（因为TCP用的不是停等协议），第三个报文段丢失了，这时候ACK来了

主机B返回ACK，如图所示

第二阶段：
主机A调整发送窗口大小为300B，并且接连发送并重传丢失报文，这时候刚好满300，于是就等待ACK

主机B返回ACK，如图所示

第三阶段：
主机A调整发送窗口大小为100B，并且发送1个报文段，由于发送窗口满了，就等待ACK

主机B返回ACK，如图所示

第四阶段
主机A调整发送窗口大小为0B，所以就停止发送

这四个阶段中返回的rwnd和发送窗口大小改变就是流量控制

这里会出现问题！！！
就是连接并没有断开，而且发送不在继续，陷入了双方等待，于是TCP想了个解决方法

解决方法：TCP为每一个连接设有一个持续计时器，只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。

若持续计时器设置的时间到期，就发送一一个零窗口探测报文段。接收方收到探测报文段时给出现在的窗口值。

如果窗口还是0，就重置持续计时器（待会再来问问还能传不）

TCP拥塞控制

拥塞：在网络中就是网络堵塞（数据转发缓慢）

出现拥塞的条件:对资源需求的总和>可用资源

网络中有许多资源同时呈现供应不足→网络性能变坏→网络吞吐量将随输入负荷增大而下降

拥塞控制目的：防止过多的数据注入到网络中（这个是从全局来调控的，不是一两台电脑不发就行了）

拥塞控制和流量控制的对比

拥塞控制就是多台电脑给我发消息，我收不过来，我得管控一下，是点对多的（这个是网络慢导致）

流量控制就是你一直发我，我受不了了，发慢点，是点对点的（这个是发的太快导致）

拥塞控制的四种算法

四种算法：慢开始和拥塞避免/快重传和快恢复（为什么这个写法呢，因为这其实是两组，和起来的两种需要配合着使用）

首先由前提条件
1.数据单方向传送，而另一个方向只传送确认
2.接收方总是有足够大的缓存空间，因而发送窗口大小取决于拥塞程度

这里解释一下接受窗口和拥塞窗口
接收窗口：接收方根据接受缓存设置的值，并告知给发送方，反应接收方容量

拥塞窗口：发送方根据自己估算的网络拥塞程度而设置的窗口值，反映网络当前容量

慢开始和拥塞避免

首先解释一下传输轮次：
发送了一批报文段并收到它们的确认的时间。

一个往返时延RTT。

开始发送一批拥塞窗口内的报文段到开始发送下一批拥塞窗口内的报文段的时间。
（这个挺好理解）

然后就是在ssthresh（限定值）以下，cwnd（拥塞窗口）以指数规律增长，限定值以后线性增长（就是每次+1）

检测到拥塞以后，直接cwnd变成1，ssthresh变成拥塞前的一半（途中到24，所以变成12）

然后就是重复操作

快重传和快恢复

这个的拥塞条件并不是检测出来的，而是当丢失文件，收到3个重复的ACK就执行快重传算法

并且快恢复就是不从1开始，直接就是新的ssthresh开始线性增加（这里的ssthresh的计算方法还是一样的）

传输层总结

TCP展开太大了，懒得搞了基本就是我制作的目录