h5手机网站建设,专业模板建站哪家好,ip地址能安装wordpress,江苏网站建设开发前面已经介绍了传输层的UDP协议的报文以及一下相关的知识点#xff0c;本次主要是传输层的TCP协议#xff0c;包括TCP报文的详细介绍#xff1b;可靠传输、流量控制、拥塞控制等#xff1b;建立连接、释放连接。
一、TCP基本知识点介绍 1.1、TCP协议的几个重要的知识点 … 前面已经介绍了传输层的UDP协议的报文以及一下相关的知识点本次主要是传输层的TCP协议包括TCP报文的详细介绍可靠传输、流量控制、拥塞控制等建立连接、释放连接。
一、TCP基本知识点介绍 1.1、TCP协议的几个重要的知识点 1TCP报文的具体内容。 2可靠传输。 如果服务器响应给客户端的数据太大那么会切成不同的包一次发过去。客户端每接收一个包都会给服务 器一个回应我收到这个了这个包。服务器就会知道这个给包成功发送了。 如果有一个包在发送过路程中被路由器丢掉了那么客户端收不到这个包服务器也就收不到客户端给 服务器关于接收到这个包的响应。那么服务器在之后就会重新再发送一遍这个包。 3流量控制。 4拥塞控制。 5建立连接。 6释放连接。
1.2、TCP报文具体内容 TCP协议报文段首部包含两个部分 120个字节的固定首部部分 2选项和填充部分长度不固定
所以TCP协议报文段的首部最少20个字节。 下面将详细介绍TCP的报文的具体内容
1.2.1、数据偏移 占4位取值范围是0x0101~0x1111。 乘以4就是TCP报文段的首部长度最小20~最大60字节。 因为TCP报文段首部最小是20字节所以数据偏移的最小值是20/450x0101。 这部分和网络层首部一样。 TCP首部长度就是右边数据向右的偏移量。
1.2.2、保留 占3位目前用不到。预防以后可能用到现在全是0。
1.2.3、标志位 如下图所示的红色框内的6位就是TCP报文中的标志位。 1共占9位、前三位是保留位与保留位无关 2URGUrgent 当URG1时紧急指针字段才有效。表明当前报文字段中有紧急数据优先传输。 3ACKAckownledgment 当ACK1时确认号ack字段才有效。
4PSHPush 一般不关注用在交互式网络通信中。
5RSTReset 当RST1时表明连接中出现严重差错必须释放连接然后再重新建立连接。
6SYNSynchronization 1.当SYN1ACK0时表明这是一个建立连接的请求。 2.若对方同意建立连接则回复SYN1ACK1。 3.三次握手中用户端恢复后会给应答SYN0ACK1。
7FINFinish 当FIN1时表明数据已经发送完毕要求释放连接。 TCP的四次挥手释放连接的时候使用的标志位中主要的就是FIN标志位。
8TCP校验和-Checksum 1.跟UDP一样TCP校验和的计算内容伪首部首部数据 2.伪首部占用12字节仅在计算校验和时起作用并不会传递给网络层。
9序号Sequence Number 1.占4字节4*832个位。 2.首先在传输过程中的每一个字节都会有一个编号而且连续的字节编号也连续。类似于每一个字节都有一个内存地址。 3.在建立连接后序号代表这一次传给对方的TCP数据部分的第一个字节的编号。
例子 比如A要发给B400字节的数据分成4段发。第一个TCP报文段的数据部分是1~100那么这个报文段的序号部分就是1假设第一个字节的编号就是1。 那么第二个报文段的数据部分就是101~200这个报文段的序号部分就是101。
10确认号Ackownledgment Number 1.占4字节4*832个位。 2.在建立连接后确认号代表期望对方下一次传过来的TCP数据部分的第一个字节的编号。 3.确认号ack在标志位ACK为1时才有效。重要
11窗口Window 1.占2字节2*816位 2.这个字段有流量控制功能用于告诉对方下一次允许发送的数据大小单位字节。
1.2.4、TCP报文内容的细节
1TCP中并没有报文总长度的概念只知道数据偏移也就是TCP报文的头部这时候如何确定TCP数据部分的长度 1.UDP首部中有个16位的字段记录了整个UDP报文段的长度首部数据 但是TCP首部中仅仅有4位的字段记录了TCP报文段的首部长度并没有字段记录TCP报文段的数据长度。 2.那怎么知道TCP报文段的数据长度呢 1.其实UDP首部的这个记录UDP报文段的长度的字段是冗余的不用这个字段也能就计算出UDP报文数据部分 的长度 UDP首部固定是8字节 所以UDP数据部分是网络层的总长度-网络层的首部长度-UDP报文首部长度 2.UDP的这个16位的字段纯粹是为了保证首部是32bit对齐 思考数据偏移*4代表了TCP报文段首部的长度那么TCP报文首部长度能不能等于11可能不行啊 必须是4的倍数。所以这个16位的记录UDP报文段的长度的字段之所以占16位就是为了满足UDP报文段 首部固定部分长度是4的倍数如果没有这16位那么UDP报文段首部固定部分长度3个字节就不是4的倍数 了。 3.所以TCP/UDP的数据长度完全可以由IP数据包的首部推测出来。 传输层的首部长度是固定的或者可知的 1.UDP首部20字节 2.TCP首部存放在首部的数据偏移字段 3.网络层的总长度和首部长度都有对应字段存储。 传输层数据部分是网络层的总长度-网络层的首部长度-传输层报文首部长度
2TCP报文的标志位的个数 1.保留为6位标志位6位。 但是其实两种说法差不多因为标志位的前3位也是基本上不用的所以会被算作保留位。 所以有些资料干脆说保留位6位标志位6位。
1.3、TCP可靠传输
1.3.1、实现TCP可靠传输 -- 停止等待ARQ协议
ARQAutomatic Repeat-reQuest自动重传请求。 1.假设A要发送给B发送3个包如果发送第一个包M1时B没有接收到。那么B就不会给A发送确认收到M1包这个消息。然后A端等待接收这个消息直到超时。然后就会重新发送M1包。 2.停止等待ARQ协议实现TCP可靠传输的两种情况 1确认信息丢失 B收到A发送的M1包然后返回一个确认信息。但是这个确认收到M1信息在传输时丢失了。那么A在 等待超时后会在次发送一个M1包此时B端接收后就会收到两个M1包B端会丢掉一个M1包再返回确 认收到M1包的信息给A端。 2确认信息迟到 B收到A发送的M1包然后返回一个确认信息。但是这个确认收到M1信息可能因为线路或者网络问题传 输的很慢可能造成A端等待超时再次发送M1包。B端接收到这第二个M1包后发现已经收到过了就 会丢掉一个M1包再次发送确认收到M1信息。 对于A端来说收到B端发送的确认收到M1信息后就会接着发送M2信息。之后可能还会再次收到确认 收到M1信息。A端收到这个迟到的确认信息发现之前收到过了那么A端就会不响应这个信息。 3.停止等待ARQ协议能够保证TCP的可靠传输但是因为必须等上一个数据传输结束下一个信息才能传输所以效率很低正是因为有这些原因所以提出了下面的改进。
1.3.2、改进连续ARQ协议滑动窗口协议SACK选择性确认 1.连续ARQ发送窗口中有4个分组会一口气发送完然后再等待确认信息。而且确认信息也只会发送确认 收到最后一个分组的确认信息。等价于确认收到所有分组信息了。 2.滑动窗口B这边有一个缓存窗口用来暂时存放每次从A发送来的数据。这个窗口的大小会告诉A。窗口的 大小代表每次最多能能接收多少分组。发送方的窗口大小一般是由接收方决定的。 3.图示一个传输过程注意序号Seq和确认号ack图中的ACK标志位有效的时候TCP报文中的确认号ack才有效。 如上图所示的第二次A给B连续发送四个数据包的时候发现了丢失反码B给A的回复就是“ACK1ack601”也就是从丢包的位置开始上传丢包的前面的包不需要在从新上传后面的也不需要从新上传。
4.SACK选择性确认Selective Acknowledgment 1.在TCP通信过程中如果发送序列中间某个数据包丢失比如12345中的3丢失了。 TCP会通过重传最后确认的分组2的后续分组345收到的确认信息中的确认分组是2那么发 送端会重传345。这样原先已经正确传输的分组也可能重复发送比如45降低了TCP性能。 2.为改善上述情况发展了SACK(Selective Acknowledgment)技术 告诉发送方哪些数据丢失哪些数据已经提前收到。可以使TCP只重新发送丢失的包比如3不用发送 后续所有的分组比如45。 3.SACK信息会放在 TCP首部 的 选项部分 此时TCP首部的选项部分就是SACK选项。这样TCP的选项部分就使用上啦TCP的首部就变长了。 1.3.3、抓包演示 1前面5个发了5个分组。 前面5个包大小分别是312、1280、1280、1280、1280并且返回的确认号都是748说明用户端没有进行回应。
2后面1个用户给服务器回复一个确认信息。 用户确认收到了5432字节请给我发送5433及之后的字节我的窗口大小是262400。
3注意服务器发给我的第一个包的Seq是1但是其实这个序号是相对序号。 相对于谁的序号呢注意到下面还有个原始(raw)序号那么原始序号 - 相对序号 基准数。 3277832203 - 1 3277832202 看第二个包得到基准数也是3277832202 4这个基准数其实是一个标识标识这些连接属于同一个请求。这个值在TCP连接的时候创建的并且告诉对方。
5序号部分放的是原始值Sequence Number(raw)而不是相对值。
1.3.4、疑问解决
1如果一个包重传了N次还是失败会一直持续重传到成功为止吗 这个取决于操作系统的设置比如有些操作系统重传5次还未成功就会发送reset报文RST断开TCP。 即发送端超出一定的重传次数或等待时间还没有收到来自接收端的确认报文于是发送reset报文。 当RST1时表明连接出现严重错误必须释放连接然后再重新建立连接。
2如果接收窗口最多能接收4个包但是发送方只发送了2个包接收方如何确定后面还有没有第3个包呢 等待一定时间后还是没有第3个包发过来接收端就认为只传过来了2个包无论是传输过程中丢包还是只有2 个包。接收端就会返回确认信息确认收到2个包。
3为什么选择在传输层就将数据“大卸八块”分成多个段而不是等到网络层再分片传递给数据链路层 因为可以提高重传的性能需要明确的是可靠传输是在传输层进行控制的即没有收到确认信息后发送 端会重新发送这个报文段。 所以如果在传输层不分段一旦出现数据丢失整个传输层的数据都得重传。 如果在传输层分了段一旦出现数据丢失只需要重传丢失的那些段即可。
1.4、流量控制 1如果接收方的缓存区满了发送方还是疯狂的发送数据接收方只能把收到的数据包丢掉大量的丢包会极大着浪费网络资源。所以要进行流量控制。 2什么是流量控制让发送方的发送速率不要太快让接收方来得及接收处理。 3缓存区和窗口是不同的概念缓存区要比窗口大很多每次收到一窗口大小的数据会先放到缓存区中。 4原理 通过确认报文中窗口字段来控制发送方的发送速率也就是实时调整窗口大小。 发送方的发送窗口大小不能超过接收方给出的窗口大小 当发送方收到接收窗口的大小为0时发送方就会停止发送数据。 5流量控制特殊情况 1.有一种特殊情况一开始接收方给发送方发送了报文段中的窗口字段值为0。后面接收方又有了一些存储 空间会给发送方发送一个非0窗口的报文但是这个报文丢了。 2.结果就是发送方一直认为接收方的窗口为0不发送报文接收方一直等不到数据一直等待双方陷入 僵局。 3.解决方案发送方主动询问窗口大小。 当发送方收到窗口为0的报文时发送方会停止发送报文但是同时会开启一个定时器隔一段时间就发个测 试报文去询问接收方最新的窗口大小。如果接收方的窗口大小还是0则发送方会再次刷新启动这个定时器。
1.5、拥塞控制 1.5.1、什么是拥塞
1.如果一个路由器R3允许通过的最大带宽是1000M此时R3路由器左侧又连接这个两个路由器R1和R2R1的最大带宽是700MR2的最大带宽是600M。那么此时就极有可能发生拥塞现象。 在理想情况下R3能同时允许1000M的数据通过但是R1和R2最多能通过1300M。此时就可能发生R3路由器来不及处理这么多数据或者无法一次性通过这么多数据就会造成拥塞现象。R3就会丢弃掉过载的数据包。 拥塞是指到达通信子网中某一部分的分组数量过多使得该部分网络来不及处理一致引起这个部分乃至整个网络性能下降的现象严重时甚至会导致网络通信业务陷入停顿即出现死锁现象。
2.理想情况和实际情况是不同的 如果某个链路的理想情况下的吞吐量是1000M但是实际情况由于数据可能在传输过程中可能会互相干扰。往往实际负载在不到1000M时该链路的吞吐量就达到最大了。 之后再加大负载就会造成拥塞。
1.5.2、拥塞控制 1防止过多的数据注入到网络中避免网络中的路由器或链路过载。 2拥塞控制是一个全局性的过程流量控制是两端点对点的控制过程。 要整个链路来协同控制涉及到所有的主机路由器以及与降低网络传输性能有关的所有因素是大家共 同努力的结果。
1.5.3、几个单词缩写意思
1MSSMaxium Segment Size每个段的数据部分的最大长度 两端建立连接时会商定一个合适的MSS值即MSS在建立连接时确定。 每个段数据部分最大值的理论值1460字节. 抓包观察这个字段
首先这个MSS段的数据部分的最大长度是在建立连接时确定的那肯定是在三次握手时确定的
当SYN1ACK0时表明这是一个建立连接的请求。 查看这个TCP报文的首部发现TCP首部长度是32字节所以有12字节在选项Options部分中。
在Options部分中发现了MSS字段且是1460注意这个值不是固定的两端发送的的TCP报文中这个值可能是 不一样的。 这个选项部分Options就是存放两端确定的一些东西
比如MSS段的数据部分的最大长度是否允许SACK 选择性确认SACK permitted 注意这个值不是固定的两端发送的的TCP报文中这个值可能是不一样的。
比如A发给B的报文中MSS是1460B发给A的报文中MSS是1412那么此时MSS在两者中取最小值。为了兼 顾两者这样传输数据两者都能接收。
MSS在建立连接时确定协商的。 2.cwnd(congestion window)拥塞窗口 进行拥塞控制会动态的变化。 3.rwnd(receive window)接收窗口 接收方告诉发送方你最多一次能发送多少的TCP报文段。 4.swnd(send window)发送窗口 swnd min(cwnd, rwnd) 实际发送方的发送窗口取拥塞窗口和接收窗口的最小值。
1.5.4、拥塞控制的方法
1慢开始slow start慢启动 加入一开始接收方告诉发送方的接收窗口rwnd3000比较大且MSS100比较小。所以理论上发送方可以以口气发30个报文段给接收方。但是考虑到拥塞控制的话拥塞窗口cwnd100一开始会设置的比较小。那么发送窗口swnd会取拥塞窗口cwnd和接收窗口rwnd两者的最小值100所以第一次会只发送1个报文段。 发送一个报文段后发现网络状况良好。那么拥塞窗口会 * 2cwnd200。发送窗口取两者最小值为swnd200所以这次发送2个报文段。发现网络状况依然良好拥塞窗口继续 * 2cwnd400。下一次发送4个报文段如果网络状况依然良好的话拥塞窗口cwnd * 2。 发送窗口缓慢增长试探增长慢慢开始。试探接收方的接收程度。 cwnd的初始值比较小然后随着TCP报文段被接收方确认收到一个ACK而成倍增长指数级。 2拥塞避免congestion avoidacne 1.在慢开始的基础上为拥塞窗口cwnd加上一个慢开始阈值slow start thresholdcwnd在到达阈值之前只要网络良好没有出现拥塞等状况就会成指数增长乘以2如果达到阈值而且网络状况依然良好拥塞窗口cwnd会呈乘法级增长每次加固定值。 2.当出现拥塞时发现开始丢包/报文段就会把慢开始阈值slow start threshold减半同时从头开始执行慢开始算法cwnd从初始值开始。 3.ssthresh(slow start threshold)慢开始阈值cwnd达到阈值后以线性方式增长。 4.拥塞避免加法增大拥塞窗口缓慢增大以防止网络过早出现拥塞。 5.乘法减小只要网络出现拥塞发现开始丢包了把ssthresh减半与此同时开始重新执行慢开始算法。 6.当网络出现频繁拥塞的话ssthresh这个值会下降的很快。
3快速重传fast restransmit 1.之前的实现TCP可靠传输时有一个重传机制是“超时重传”。在ARQ自动重传请求机制中如果A等待接受B的确认消息如果等待超时的话就会重新发送上一个报文段。 2.快重传机制在接收方和发送方都进行了限制 3.接收方 之前的做法A发送5个段给B时B只有等A的5个都发送完时或最后一个段超时时才给A发确认信息我 收到了哪些段。 快重传做法当接收方收到第二个分组后返回一个确认收到分组2。但是没有收到第三个分组直接收 到了分组4即收到了一个失序的分组。那么在收到分组4后会立即发出重复的确认上一个确认信 息确认收到了分组2。然后继续收到分组5再次发送确认收到了分组2然后继续收到分组6再次发 送确认收到了分组2。 4.发送方 如果连续收到3个重复的确认总共4个相同的确认就会立即重传尚未收到的报文段。
而不必继续等待重传计时器到期后再重传。
4快速恢复fast recovery 1.拥塞控制是上述4个方法综合来治理的。 2.大致过程 慢开始算法开始增大拥塞窗口当拥塞窗口以指数增长直到达到慢开始阈值后执行拥塞避免算法即 拥塞窗口以线性增长。当收到3个重复的确认后意识到此时开始掉包产生拥塞了----慢开始阈值乘法减 半变成以前的一半 之后又重新开始“慢开始算法”拥塞窗口重初始值开始呈指数增长这是旧版本的做法已经弃置不 用。但是这样效率较低拥塞窗口应该在一个合适的初始值开始增大。 拥塞窗口直接以新的慢开始阈值作为初始值开始以线性增长。 3.当发送方连续收到3个重复确认后就意识到此时发生了丢包的现象可能出现了拥塞。就执行“乘法减 小”把慢开始阈值减半。之后不会执行慢开始算法而是将拥塞窗口的值直接设置为慢开始阈值减半后的 新阈值并且呈线性增长。
5发送窗口的限制条件 1.发送窗口的最大值swnd min(cwnd, rwnd) cwnd指网络的拥塞窗口 2.当rwnd cwnd时是接收方的接收能力限制发送窗口的最大值。 3.cwnd rwnd时则是网络的拥塞限制发送窗口的最大值。
6拥塞控制可以理解为是在可靠传输流量控制的基础上进一步来控制网络的状态协调网络的情况。尽量避免网络拥塞出现状况。 二、TCP连接管理 1建立连接 三次握手 2释放连接 四次挥手 2.1、序号、确认号的值
2.1.1、序号、确认号的基本过程值 在发送一个http请求前要先建立一个稳定的连接。 1序号和确认号概念 序号Seq我当前发的包的数据部分的第一个字节的编号在分段之前的整个数据包的编号。
可以理解为我当前这个包的数据从哪个字节发。 确认号Ack在建立连接后确认号代表期望对方下一次穿过来的TCP数据部分的第一个字节的编号。 也可以理解我确认收到了这个编号前面字节的数据。确认号Ack只有在标志位ACK为1时明才有效。
2序号确认号相对值的确定 下面的图片描述是比较书本的情况实际情况可能是连发好几个数据包才会回应一次。
