| TCP几个要点 | 您所在的位置：网站首页 › number1啥意思 › TCP几个要点 |
TCP几个要点
|
TCP几个要点
可靠传输
在网络传输中发生网络包的丢失（可能是因为网络抖动，或者发生了拥堵），导致包超时抵达，就会丢弃超时的包，重新发送，如果超时的包在在一段时间内又发成功了，接收端也不做什么处理
简单理解：就是发送的数据包丢了，需要重新发送
问题：
若有个包重传了N次还是失败，会一直持续重传到成功为止么？
这个取决于系统的设置，比如有些系统，重传5次还未成功就会发送reset报文（RST）断开TCP连接
问题：
为什么选择在传输层就将数据“大卸八块”分成多个段，而不是等到网络层再分片传递给数据链路层？
因为可以提高重传的性能
需要明确的是：可靠传输是在传输层进行控制的
如果在传输层不分段，一旦出现数据丢失，整个传输层的数据都得重传
如果在传输层分了段，一旦出现数据丢失，只需要重传丢失的那些段即可
流量控制
点对点，发送方发送的速率不要太快，让接收方来得及处理，发送方每次在发送数据包得时候到接收方时，接收方都会携带自己得接收窗口大小（肯定会发送一个ACK（确认号）给发送方）
提示情况：
一开始，接收方给发送方发送了0窗口的报文段
后面，接收方又有了一些存储空间，给发送方发送的非0窗口的报文段丢失了
发送方的发送窗口一直为零，双方陷入僵局
解决方案
当发送方收到0窗口通知时，这时发送方停止发送报文
并且同时开启一个定时器，隔一段时间就发个测试报文去询问接收方最新的窗口大小
如果接收的窗口大小还是为0，则发送方再次刷新启动定时器
拥塞控制
防止过多得数据注入到网络中，避免网络中得路由器或链路过载拥塞控制是一个全局性得过程，涉及到主机、路由器以及与降低网络传输性能有关的所有因素
拥塞控制4中方法
cwnd：拥塞端口
慢开始：cwnd的初始值比较小，然后随着数据包被接收方确认cwnd就成倍增长（指数级）
拥塞避免：拥塞窗口缓慢增大，以防止网络过早出现拥塞，
慢开始+拥塞避免：一开始慢开始 cwnd以成倍增长，线性增加，出现拥塞避免（以加法增大cwnd得值），当出现网络拥塞（丢包），以cwnd减小一半，同时执行慢开始算法，从起点开始增加。
快重传：
接收方：每收到一个失序的分组后就立即发出重复确认，使发送方及时知道有分组没有到达而不要等待自己发送数据时才进行确认
发送发：只要连续收到三个重复确认（总共4个相同的确认），就应当立即重传对方尚未收到的报文段，而不必继续等待重传计时器到期后再重传
快恢复：当发送方连续收到三个重复确认，说明网络出现拥塞，就把cwnd峰值减半，即cwnd不会恢复初始值，然后开始执行拥塞避免算法（以加法增大cwnd得值）
每次发送数据包的人可能是服务器端也有可能是客户端 这么大的值是怎么来的？建立连接的时候来的，建立连接的时候TCP的数据部分为0个字节 因为在TCP建立连接的时候这个序号就已经确认下来了 比如：我这里说的都是原始的Seq的值，还没到传送数据包的时候，只是建立连接时 SYN：同步连接请求，SYN=1时，不携带任何数据部分 ACK: 回应客户端发来的请求，做出响应 当ACK=0的时候，确认号里面的数据没意义 Ack：建立连接后确认号（期望对方下一次传过来的TCP数据部分的第一个字节的编号），确认你发送的数据为多少假如为n，下一次发送的数据就为n。 Seq：建立连接后,表示传给对方数据的第一个字节编号 第一次建立连接的序号SYN=1，ACK=0，Seq是一个随机的值比如为123456
第二次建立连接的序号SYN=1，ACK=1，Seq也是一个随机的值比如为456789
第三次建立连接的序号SYN=0，AcK=1。Seq是在第一次建立连接Seq的基础上+1，
原生 客户端发送数据： 比如 客户端Seq = 123456 +1 ，Len = 100 Ack= 123456 +1 + 100 客户端的初始序号：用到客户端的序号里面 和 服务器的Ack里面 服务器发送数据： 比如：服务器端Seq = 456789 +1 .Len = 100 服务器端的初始序号：用到服务器端的序号里面 和 客户端的Ack里面 Ack = 456789 + 1 + 100 序号和确认号计算在建立连接的时候，双方是不进行数据的传输 通过抓包可以看出在进行TCP传输数据的时候，首先会进行三次握手，后就会一次http的请求，之后就会进行数据之间的交互发送端可能会发送多次数据，接收端回复Ack后这一段的数据传输完成，http也回复对应的信息，之后继续进行数据的传输
只有前两次SYN=1，后面SYN都等于0 客户端：SYN=0，ACK=1，客户端确认服务器连接，Seq=1，为什么呢，因为第二次服务器Ack=1，希望我客户端发送从1开始的数据，Ack也为1，上一次发送的数据为0，期望从1开始发送数据 客户端发送一个HTTP请求并且携带了K个数据，Seq=1，因为你上次ACK=1，希望我发送从1开始的数据，ACK=1，对上一次的做出的数据结结果，也就是第二次服务器给客户端传递的数据 ，因为服务器给客户端的数据为0，希望客户端给我传下一个数据的第一个字节给我，有点绕，总的来说，收发数据可能是客户端也可能是服务器端，要弄清楚谁给谁发数据，Ack就找发送数据的那一方 ACK：期望对方下一次传（是传可能是客户端传给服务器端，也有可能是服务器传给客户端）过来的的TCP数据（也就是说是发送方既有可能是服务器端，也有可能是客户端）的部分的第一个字节
上面都是对应相对的值，但是原生的值还没有，在进行客户端和服务器端建立连接的时候都会生成自己的seq这个值很大。 图中很明显 怎样计算原生的值呢？ 想必你弄清除了你就会发现 客户端的Seq初始值在哪里会使用的到呢? 在客户端的发送的Seq中和在服务端的Ack中 服务端的Seq初始值在哪里会使用的到呢？ 在服务端发送的Seq中和在客户端的Ack中 弄清楚这个其实就好懂了 因为客户端和服务器端都会生成自己对的的Seq的值。这个值往往会很大 1、发送端是哪一个Seq就是Seq的值就是发送端的具体值，而服务器端的Ack则需要看发送数据的也就是客户端发送的数据来确认 比如客户端作为发送给服务器数据的一端也叫发送端，Seq就是客户端生成的值，而服务器Ack（回应客户端）接收的值也是从客户端发送值来确定的，所有客户端的Seq也会出现在服务器端里面 而服务器端作为接收客户端发送来的数据的一端也叫接收端，Seq也就是服务器端生成的值，而客户端的Ack（回应服务器端）接收的值也是错服务器端发送来确认的，所有服务器端的Seq也会出现在客户端里面可能解释的不够清楚，不过需要知道Seq和Ack这两个之间的关系就大致理解了 Seq：表示每次需要发送数据的前第1个字节 Ack：表示这次发送的字节数我接收到了，给发送端一个回应，希望下次发送的字节数 问题：为什么需要这么大的值如果在TCP首部里面的序号和确认号他们同时占据4个字节，如果给一个很小的数1个字节就够了，不可能需要4个字节来存储，显然不可能让一个很小的数字占据4个字节。 在抓包中可以看到对应的字段 Sequence Number（relative sequence number）：这个字段，小括号里翻译为相对序列号， 不是具体的序号。 Sequence Number（raw）：才是原始的值 Acknowledgment Number: (relative ack number)：这个字段，小括号翻译为相对确认号，不是具体的确认号 Acknowledgment Number （raw）: 才是原始的值 最后如果需要详细的看到TCP段的数据还是需要自动动手去抓包查看，我在此已经准备好了需要的自行下载 链接：https://pan.baidu.com/s/1bOM30F_uI49WOCsbUZu9nQ 提取码：1r82 |
怎样计算相对值呢？
【本文地址】