计算机学习笔记(二)
文章目录
-
- 1. 介绍一下tcp的四次挥手。
- 2.为什么需要四次挥手？
- 3 .为什么要有最后一次ACK？
- 4. 介绍一下tcp粘包、拆包的机制。
- 5. 介绍一下TCP和UDP的区别。
- 6 .TCP和UDP对于网络稳定性有什么要求？
- 7. 如何让UDP可靠一些？
- 8. TCP报文首部中序号占多少字节？
- 9. TCP中的缓存有什么作用？
- 10. 说一说TCP是怎么控制流量的？
- 11. HTTP2.0中TCP阻塞了怎么办？
- 12.TCP如何保证可靠性？
1. 介绍一下tcp的四次挥手。
- 客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
- 服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
- 客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
- 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
- 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
- 服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。
2.为什么需要四次挥手？
-
四次挥手示意图
-
四次挥手过程
（1）客户端向服务器发送FIN控制报文段（首部中的 FIN 比特被置位）；
（2）服务端收到FIN，回复ACK。服务器进入关闭等待状态，发送FIN;
（3）客户端收到FIN，给服务器回复ACK，客户端进入等待状态（进入“等待”，以确保服务器收到ACK真正关闭连接）;
（4）服务端收到ACK，链接关闭。
-
四次挥手原因
TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当客户端发出FIN报文段时，只是表示客户端已经没有数据要发送了，客户端告诉服务器，它的数据已经全部发送完毕了；但是，这个时候客户端还是可以接受来自服务端的数据；当服务端返回ACK报文段时，表示它已经知道客户端没有数据发送了，但是服务端还是可以发送数据到客户端的；当服务端也发送了FIN报文段时，这个时候就表示服务端也没有数据要发送了，就会告诉客户端，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。
简单地说，前 2 次挥手用于关闭一个方向的数据通道，后两次挥手用于关闭另外一个方向的数据通道。
3 .为什么要有最后一次ACK？
-
三次握手示意图
-
四次挥手过程
（1）客户端发送一个SYN0给服务器（选择初始序列号，不携带任何数据）
（2）服务器收到SYN0，回复SYN1和ACK（服务器分配缓存，选择自己初始序列号）
（3）客户端收到SYN1、ACK，回复ACK（可以包含数据）
-
为什么要有最后一次ACK
客户端首先向服务器发送一个连接请求，但是可能这个连接请求走了远路，等了很长时间，服务器都没有收到，那么客户端可能会再次发送，此时服务器端收到并且回复SYN、ACK；在这个时候最先发送的那个连接请求到达服务器，那么服务器会回复一个SYN，ACK；但是客户端表示自己已经收到确认了，并不搭理这个回复，那么服务器可能陷入等待，如果这种情况多了，那么会导致服务器瘫痪，所以要发送第三个确认。
4. 介绍一下tcp粘包、拆包的机制。
-
TCP粘包和拆包问题
TCP是一个“流”协议，所谓流，就是没有界限的一长串二进制数据。TCP作为传输层协议并不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行数据包的划分，所以在业务上认为是一个完整的包，可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是所谓的TCP粘包和拆包问题。
-
产生TCP粘包和拆包的原因
我们知道TCP是以流动的方式传输数据的，传输的最小单位为一个报文段（Segment）。TCP Header中有个Options标识位。常见的标识位为MSS（Maximum Segment Size）指的是，连接层每次传输的数据有个最大限制MTU（Maximum Transmission Unit），一般是1500bit，超过这个量要分成多个报文段，MSS则是这个最大限制减去TCP的header，光是要传输的数据的大小，一般为1460bit。换算成字节，也就是180多字节。 TCP为提高性能，发送端会将需要发送的数据发送到缓冲区，等待缓冲区满了以后，再将缓冲中的数据发送到接收方。同理，接收方也有缓冲区这样的机制来接受数据。 发生TCP粘包、拆包主要是以下原因： （1）应用程序写入数据大于套接字缓冲区大小，会发生拆包； （2）应用程序写入数据小于套接字缓冲区大小，网卡将应用多次写入的数据发送到网络上，这将会发送粘包； （3）进行MSS（最大报文长度）大小的TCP分段，当TCP报文长度——TCP header长度>MSS 的时候会发生拆包； （4）接收方法不及时读取套接字缓冲区数据，这将发生粘包。
-
如何处理粘包和拆包
假设应用层协议是http
我从浏览器中访问了一个网站，网站服务器给我发了200k的数据。建立连接的时候，通告的MSS是50k，所以为了防止ip层分片，tcp每次只会发送50k的数据，一共发了4个tcp数据包。如果我又访问了另一个网站，这个网站给我发了100k的数据，这次tcp会发出2个包，问题是，客户端收到6个包，怎么知道前4个包是一个页面，后两个是一个页面。既然是tcp将这些包分开了，那tcp会将这些包重组吗，它送给应用层的是什么？这是我自己想的一个场景，正式一点讲的话，这个现象叫拆包。
我们再考虑一个问题。
tcp中有一个negal算法，用途是这样的：通信两端有很多小的数据包要发送，虽然传送的数据很少，但是流程一点没少，也需要tcp的各种确认，校验。这样小的数据包如果很多，会造成网络资源很大的浪费，negal算法做了这样一件事，当来了一个很小的数据包，我不急于发送这个包，而是等来了更多的包，将这些小包组合成大包之后一并发送，不就提高了网络传输的效率的嘛。这个想法收到了很好的效果，但是我们想一下，如果是分属于两个不同页面的包，被合并在了一起，那客户那边如何区分它们呢？这就是粘包问题。
从粘包问题我们更可以看出为什么tcp被称为流协议，因为它就跟水流一样，是没有边界的，没有消息的边界保护机制，所以tcp只有流的概念，没有包的概念。
我们还需要有两个概念：
（1）长连接： Client方与Server方先建立通讯连接，连接建立后不断开， 然后再进行报文发送和接收。 （2）短连接：Client方与Server每进行一次报文收发交易时才进行通讯连接，交易完毕后立即断开连接。此种方式常用于一点对多点 通讯，比如多个Client连接一个Server。
实际，我想象的关于粘包的场景是不对的，http连接是短连接，请求之后，收到回答，立马断开连接，不会出现粘包。 拆包现象是有可能存在的。
处理拆包这里提供两种方法：
（1）通过包头+包长+包体的协议形式，当服务器端获取到指定的包长时才说明获取完整。 （2） 指定包的结束标识，这样当我们获取到指定的标识时，说明包获取完整。
处理粘包我们从上面的分析看到，虽然像http这样的短连接协议不会出现粘包的现象，但是一旦建立了长连接，粘包还是有可能会发生的。处理粘包的方法如下：
（1）发送方对于发送方造成的粘包问题，可以通过关闭Nagle算法来解决，使用TCP_NODELAY选项来关闭算法。
（2）接收方没有办法来处理粘包现象，只能将问题交给应用层来处理。应用层的解决办法简单可行，不仅能解决接收方的粘包问题，还可以解决发送方的粘包问题。解决办法：循环处理，应用程序从接收缓存中读取分组时，读完一条数据，就应该循环读取下一条数据，直到所有数据都被处理完成，判断每条数据的长度的方法有两种：
a. 格式化数据：每条数据有固定的格式（开始符，结束符），这种方法简单易行，但是选择开始符和结束符时一定要确保每条数据的内部不包含开始符和结束符。
b. 发送长度：发送每条数据时，将数据的长度一并发送，例如规定数据的前4位是数据的长度，应用层在处理时可以根据长度来判断每个分组的开始和结束位置。
答案解析
扩展资料
UDP会不会产生粘包问题呢？
TCP为了保证可靠传输并减少额外的开销（每次发包都要验证），采用了基于流的传输，基于流的传输不认为消息是一条一条的，是无保护消息边界的（保护消息边界：指传输协议把数据当做一条独立的消息在网上传输，接收端一次只能接受一条独立的消息）。UDP则是面向消息传输的，是有保护消息边界的，接收方一次只接受一条独立的信息，所以不存在粘包问题。
举个例子：有三个数据包，大小分别为2k、4k、6k，如果采用UDP发送的话，不管接受方的接收缓存有多大，我们必须要进行至少三次以上的发送才能把数据包发送完，但是使用TCP协议发送的话，我们只需要接受方的接收缓存有12k的大小，就可以一次把这3个数据包全部发送完毕。
5. 介绍一下TCP和UDP的区别。
TCP和UDP有如下区别：
- 连接：TCP面向连接的传输层协议，即传输数据之前必须先建立好连接；UDP无连接。
- 服务对象：TCP点对点的两点间服务，即一条TCP连接只能有两个端点；UDP支持一对一，一对多，多对一，多对多的交互通信。
- 可靠性：TCP可靠交付：无差错，不丢失，不重复，按序到达；UDP尽最大努力交付，不保证可靠交付。
- 拥塞控制/流量控制：有拥塞控制和流量控制保证数据传输的安全性；UDP没有拥塞控制，网络拥塞不会影响源主机的发送效率。
- 报文长度：TCP动态报文长度，即TCP报文长度是根据接收方的窗口大小和当前网络拥塞情况决定的；UDP面向报文，不合并，不拆分，保留上面传下来报文的边界。
- 首部开销：TCP首部开销大，首部20个字节；UDP首部开销小，8字节（源端口，目的端口，数据长度，校验和）。
- 适用场景（由特性决定）：数据完整性需让位于通信实时性，则应该选用TCP 协议（如文件传输、重要状态的更新等）；反之，则使用 UDP 协议（如视频传输、实时通信等）。
6 .TCP和UDP对于网络稳定性有什么要求？
-
TCP优缺点
优点：可靠、稳定
TCP的可靠体现在TCP在传输数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完之后，还会断开连接用来节约系统资源。
缺点：慢，效率低，占用系统资源高，易被攻击
在传递数据之前要先建立连接，这会消耗时间，而且在数据传递时，确认机制、重传机制、拥塞机制等都会消耗大量时间，而且要在每台设备上维护所有的传输连接。然而，每个链接都会占用系统的CPU、内存等硬件资源。因为TCP有确认机制、三次握手机制，这些也导致TCP容易被利用，实现DOS、DDOS、CC等攻击。
-
UDP优缺点
优点：快，比TCP稍安全
UDP没有TCP拥有的各种机制，是一个无状态的传输协议，所以传递数据非常快，没有TCP的这些机制，被攻击利用的机制就少一些，但是也无法避免被攻击。
缺点：不可靠，不稳定
因为没有TCP的那些机制，UDP在传输数据时，如果网络质量不好，就会很容易丢包，造成数据的缺失。
-
适用场景（网络稳定性要求）
TCP：当对网络通讯质量有要求时，比如HTTP、HTTPS、FTP等传输文件的协议， POP、SMTP等邮件传输的协议
UDP：对网络通讯质量要求不高时，要求网络通讯速度要快的场景。
所以，TCP对网络稳定性要求高，而UDP相对弱一些。
7. 如何让UDP可靠一些？
-
为什么需要可靠的UDP
在弱网（2G、3G、信号不好）环境下，使用 TCP 连接的延迟很高，影响体验。使用 UDP 是很好的解决方案，既然把 UDP 作为弱网里面的 TCP 来使用，就必须保证数据传输能像 TCP 一样可靠
-
如何实现可靠的UDP
UDP它不属于连接型协议，因而具有资源消耗小，处理速度快的优点，所以通常音频、视频和普通数据在传送时使用UDP较多，因为它们即使偶尔丢失一两个数据包，也不会对接收结果产生太大影响。传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。关键在于两点，从应用层角度考虑：
（1）提供超时重传，能避免数据报丢失。
（2）提供确认序列号，可以对数据报进行确认和排序。
本端：首先在UDP数据报定义一个首部，首部包含确认序列号和时间戳，时间戳是用来计算RTT(数据报传输的往返时间)，计算出合适的RTO(重传的超时时间)。然后以等-停的方式发送数据报，即收到对端的确认之后才发送下一个的数据报。当时间超时，本端重传数据报，同时RTO扩大为原来的两倍，重新开始计时。
对端：接受到一个数据报之后取下该数据报首部的时间戳和确认序列号，并添加本端的确认数据报首部之后发送给对端。根据此序列号对已收到的数据报进行排序并丢弃重复的数据报。
解析
扩展资料
- 已经实现的可靠UDP：
（1）RUDP 可靠数据报传输协议；
（2）RTP 实时传输协议
为数据提供了具有实时特征的端对端传送服务；
Eg：组播或单播网络服务下的交互式视频、音频或模拟数据
（3）UDT
基于UDP的数据传输协议，是一种互联网传输协议；
主要目的是支持高速广域网上的海量数据传输，引入了新的拥塞控制和数据可靠性控制机制（互联网上的标准数据传输协议TCP在高带宽长距离的网络上性能很差）；
UDT是面向连接的双向的应用层协议，同时支持可靠的数据流传输和部分可靠的数据报服务；
应用：高速数据传输，点到点技术(P2P)，防火墙穿透，多媒体数据传输；
8. TCP报文首部中序号占多少字节？
序号字段占4个字节（32位）。
解析
TCP首部字段详细图
TCP首部包括20字节的固定首部部分及长度可变的其他选项，所以TCP首部长度可变。20个字节又分为5部分，每部分4个字节32位，如图中的5行，每行表示32位。
-
源端口和目的端口字段——各占 2 字节（16位）。端口是运输层与应用层的服务接口。运输层的复用和分用功能都要通过端口才能实现。
-
序号字段——占 4 字节。TCP 连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值则**指的是本报文段所发送的数据的第一个字节的序号。**比如分组的第一个数据包由文件的14个字节数据组成，那么该数据包所添加的序号就是1，同理第二个数据包由文件的59个字节数据组成，那么该数据包所添加的序号就是5；
-
确认号字段——占 4 字节，是期望收到对方的下一个报文段的数据的第一个字节的序号。比如接收端收到由文件14个字节数据+TCP首部组成的数据包后，删除首部提取14个字节数据，返回的确认号为5，即告诉发送端下一次应该发送文件的第5个字节及其之后字节组成的数据包过来。
-
数据偏移（即首部长度）——占 4 位，它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远，也就是TCP首部的长度。“数据偏移”的单位是 32 位字（以 4 字节为计算单位），最大1111表示15x4=60个字节，即表示TCP首部最大长度为60个字节，因此“选项”部分最多40个字节。
-
保留字段——占 6 位，保留为今后使用，但目前应置为 0。
-
这里的六位二进制位，分别表示不同含义：
（1）紧急 URG —— 当 URG = 1 时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送(相当于高优先级的数据)。 即URG=1的数据包不用排队直接优先传输。
（2）同步 SYN —— 同步 SYN = 1 表示这是一个连接请求或连接接受报文。即A想与B建立连接，发送过去的第一个数据包（第一次握手）中SYN=1；B返回的数据包（第二次握手）中SYN=1表示同意建立连接。
（3）确认 ACK —— 只有当 ACK = 1 时确认号字段才有效。当 ACK = 0 时，确认号无效。
-
窗口字段 —— 占 2 字节，用来让对方设置发送窗口的依据，单位为字节。
-
检验和 —— 占 2 字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时，要在 TCP 报文段的前面加上 12 字节的伪首部。
-
紧急指针字段 —— 占 16 位，指出在本报文段中紧急数据共有多少个字节（紧急数据放在本报文段数据的最前面）。
-
选项字段 —— 长度可变。TCP 最初只规定了一种选项，即最大报文段长度 MSS (Maximum Segment Size)是 TCP 报文段中的数据字段的最大长度。数据字段加上 TCP 首部才等于整个的 TCP 报文段。MSS 告诉对方 TCP：“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节。”其他选项有：窗口扩大选项、时间戳选项、选择确认选项（SACK）。
-
填充字段 —— 这是为了使整个首部长度是 4 字节的整数倍。
9. TCP中的缓存有什么作用？
-
TCP缓冲区是什么
每个 socket 被创建后，都会分配两个缓冲区，输入缓冲区和输出缓冲区。
-
缓冲区的意义（作用）
TCP套接字的I/O缓冲区示意图
TCP的发送缓冲区是用来缓存应用程序的数据，发送缓冲区的每个字节都有序列号，被应答确认的序列号对应的数据会从发送缓冲区删除掉。
write()/send() 并不立即向网络中传输数据，而是先将数据写入缓冲区中，再由TCP协议将数据从缓冲区发送到目标机器。一旦将数据写入到缓冲区，函数就可以成功返回，不管它们有没有到达目标机器，也不管它们何时被发送到网络，这些都是TCP协议负责的事情。 TCP协议独立于 write()/send() 函数，数据有可能刚被写入缓冲区就发送到网络，也可能在缓冲区中不断积压，多次写入的数据被一次性发送到网络，比如nagle算法，这取决于当时的网络情况、当前线程是否空闲等诸多因素，不由程序员控制。 read()/recv() 函数也是如此，也从输入缓冲区中读取数据，而不是直接从网络中读取。
-
I/O缓冲区特性
（1）I/O缓冲区在每个TCP套接字中单独存在；
（2）I/O缓冲区在创建套接字时自动生成；
（3）即使关闭套接字也会继续传送输出缓冲区中遗留的数据；
（4）关闭套接字将丢失输入缓冲区中的数据。
输入输出缓冲区的默认大小一般都是 8K，可以通过 getsockopt() 函数获取：
//代码实例（缓冲区大小获取） int servSock = socket(PF_INET, SOCK_STREAM, 0); unsigned optVal; int optLen = sizeof(int); getsockopt(servSock, SOL_SOCKET, SO_SNDBUF, (char*)&optVal, &optLen); /* 运行结果： Buffer length: 8192 */
10. 说一说TCP是怎么控制流量的？
-
所谓流量控制就是让发送发送速率不要过快，让接收方来得及接收。
-
TCP控制流量的方法
利用滑动窗口机制就可以实施流量控制。
原理就是运用TCP报文段中的窗口大小字段来控制，发送方的发送窗口不可以大于接收方发回的窗口大小。考虑一种特殊的情况，就是接收方若没有缓存足够使用，就会发送零窗口大小的报文，此时发送放将发送窗口设置为0，停止发送数据。之后接收方有足够的缓存，发送了非零窗口大小的报文，但是这个报文在中途丢失的，那么发送方的发送窗口就一直为零导致死锁。
解决这个问题，TCP为每一个连接设置一个持续计时器（persistence timer）。只要TCP的一方收到对方的零窗口通知，就启动该计时器，周期性的发送一个零窗口探测报文段。对方就在确认这个报文的时候给出现在的窗口大小（注意：TCP规定，即使设置为零窗口，也必须接收以下几种报文段：零窗口探测报文段、确认报文段和携带紧急数据的报文段）。
解析
-
TCP的滑动窗口
为了提高信道的利用率TCP协议不使用停止等待协议，而是使用连续ARQ协议，意思就是可以连续发出若干个分组然后等待确认，而不是发送一个分组就停止并等待该分组的确认。
TCP的两端都有发送/接收缓存和发送/接收窗口。TCP的缓存是一个循环队列，其中发送窗口可以用3个指针表示。而发送窗口的大小受TCP数据报中窗口大小的影响，TCP数据报中的窗口大小是接收端通知发送端其还可以接收多少数据，所以发送窗口根据接收的的窗口大小的值动态变化。
以下的几张图片就帮助理解一下滑动窗口的机制：
图1 根据B给出的窗口值，A构造出自己的发送窗口
图2 A发送了11个字节的数据
注意上图中的3个指针P1、P2、P3！此时接收窗口中接收的数据可能是失序的，但是也先存储在接收缓存之中。发送确认号的时候依然发送31，表示B期望接收的下一个数据报的标示符是31。
图3 A收到新的确认号，发送窗口向前滑动
图4 发送窗口内的序号都属于已经发送但未被确认
如果发送窗口中的数据报都属于已发送但未被确认的话，那么A就不能再继续发送数据，而需要进行等待。
图5 TCP的发送缓存和发送窗口（a）与接收缓存和接收窗口（b）
-
传输效率及Nagle算法
TCP的数据传输分为交互数据流和成块数据流，交互数据流一般是一些交互式应用程序的命令，所以这些数据很小，而考虑到TCP报头和IP报头的总和就有40字节，如果数据量很小的话，那么网络的利用效率就较低。
数据传输使用Nagle算法，Nagle算法很简单，就是规定一个TCP连接最多只能有一个未被确认的未完成的小分组。在该分组的确认到达之前不能发送其他的小分组。
但是也要考虑另一个问题，叫做糊涂窗口综合症。当接收方的缓存已满的时候，交互应用程序一次只从缓存中读取一个字节（这时候缓存中腾出一个字节），然后向发送方发送确认信息，此时发送方再发送一个字节（收到的窗口大小为1），这样网络的效率很低。
要解决这个问题，可以让接收方等待一段时间，使得接收缓存已有最够的空间容纳一个最长报文段，或者等到接收缓存已有一半的空间。只要这两种情况出现一种，就发送确认报文，同时发送方可以把数据积累成大的报文段发送。
11. HTTP2.0中TCP阻塞了怎么办？
HTTP2.0中TCP阻塞了有如下两种方法可以解决：
（1）并发TCP连接（浏览器一个域名采用6-8个TCP连接，并发HTTP请求） （2）域名分片（多个域名，可以建立更多的TCP连接，从而提高HTTP请求的并发）
解析
1. TCP队头阻塞
TCP数据包是有序传输，中间一个数据包丢失，会等待该数据包重传，造成后面的数据包的阻塞。
2. HTTP队头阻塞
http队头阻塞和TCP队头阻塞完全不是一回事。
http1.x采用长连接(Connection:keep-alive)，可以在一个TCP请求上，发送多个http请求。
有非管道化和管道化，两种方式。
非管道化，完全串行执行，请求->响应->请求->响应…，后一个请求必须在前一个响应之后发送。
管道化，请求可以并行发出，但是响应必须串行返回。后一个响应必须在前一个响应之后。原因是，没有序号标明顺序，只能串行接收。
管道化请求的致命弱点:
（1）会造成队头阻塞，前一个响应未及时返回，后面的响应被阻塞 （2）请求必须是幂等请求，不能修改资源。因为，意外中断时候，客户端需要把未收到响应的请求重发，非幂等请求，会造成资源破坏。
由于这个原因，目前大部分浏览器和Web服务器，都关闭了管道化，采用非管道化模式。
无论是非管道化还是管道化，都会造成队头阻塞(请求阻塞)。
解决http队头阻塞的方法：
（1）并发TCP连接（浏览器一个域名采用6-8个TCP连接，并发HTTP请求） （2）域名分片（多个域名，可以建立更多的TCP连接，从而提高HTTP请求的并发）
2. HTTP2方式
http2使用一个域名单一TCP连接发送请求，请求包被二进制分帧，不同请求可以互相穿插，避免了http层面的请求队头阻塞。 但是不能避免TCP层面的队头阻塞。
12.TCP如何保证可靠性？
TCP协议保证数据传输可靠性的方式主要有：校验和、序列号、确认应答、超时重传、连接管理、流量控制、拥塞控制。
-
校验和
**计算方式：**在数据传输的过程中，将发送的数据段都当做一个16位的整数。将这些整数加起来。并且前面的进位不能丢弃，补在后面，最后取反，得到校验和。 **发送方：**在发送数据之前计算检验和，并进行校验和的填充。 **接收方：**收到数据后，对数据以同样的方式进行计算，求出校验和，与发送方的进行比对。
**注意：**如果接收方比对校验和与发送方不一致，那么数据一定传输有误。但是如果接收方比对校验和与发送方一致，数据不一定传输成功。
-
序列号和确认应答
**序列号：**TCP传输时将每个字节的数据都进行了编号，这就是序列号。 **确认应答：**TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文。这个ACK报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。
序列号的作用不仅仅是应答的作用，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据。这也是TCP传输可靠性的保证之一。
-
超时重传
在进行TCP传输时，由于确认应答与序列号机制，也就是说发送方发送一部分数据后，都会等待接收方发送的ACK报文，并解析ACK报文，判断数据是否传输成功。如果发送方发送完数据后，迟迟没有等到接收方的ACK报文，这该怎么办呢？而没有收到ACK报文的原因可能是什么呢？
首先，发送方没有接收到响应的ACK报文原因可能有两点：
（1）数据在传输过程中由于网络原因等直接全体丢包，接收方根本没有接收到。
（2）接收方接收到了响应的数据，但是发送的ACK报文响应却由于网络原因丢包了。
TCP在解决这个问题的时候引入了一个新的机制，叫做超时重传机制。**简单理解就是发送方在发送完数据后等待一个时间，时间到达没有接收到ACK报文，那么对刚才发送的数据进行重新发送。**如果是刚才第一个原因，接收方收到二次重发的数据后，便进行ACK应答。如果是第二个原因，接收方发现接收的数据已存在（判断存在的根据就是序列号，所以上面说序列号还有去除重复数据的作用），那么直接丢弃，仍旧发送ACK应答。
-
连接管理
连接管理就是三次握手与四次挥手的过程，保证可靠的连接，是保证可靠性的前提。
-
流量控制
收端在接收到数据后，对其进行处理。如果发送端的发送速度太快，导致接收端的结束缓冲区很快的填充满了。此时如果发送端仍旧发送数据，那么接下来发送的数据都会丢包，继而导致丢包的一系列连锁反应，超时重传呀什么的。而TCP根据接收端对数据的处理能力，决定发送端的发送速度，这个机制就是流量控制。
在TCP协议的报头信息当中，有一个16位字段的窗口大小。在介绍这个窗口大小时我们知道，窗口大小的内容实际上是接收端接收数据缓冲区的剩余大小。这个数字越大，证明接收端接收缓冲区的剩余空间越大，网络的吞吐量越大。接收端会在确认应答发送ACK报文时，将自己的即时窗口大小填入，并跟随ACK报文一起发送过去。而发送方根据ACK报文里的窗口大小的值的改变进而改变自己的发送速度。如果接收到窗口大小的值为0，那么发送方将停止发送数据。并定期的向接收端发送窗口探测数据段，让接收端把窗口大小告诉发送端。
-
拥塞控制
TCP传输的过程中，发送端开始发送数据的时候，如果刚开始就发送大量的数据，那么就可能造成一些问题。网络可能在开始的时候就很拥堵，如果给网络中在扔出大量数据，那么这个拥堵就会加剧。拥堵的加剧就会产生大量的丢包，就对大量的超时重传，严重影响传输。
所以TCP引入了慢启动的机制，在开始发送数据时，先发送少量的数据探路。探清当前的网络状态如何，再决定多大的速度进行传输。这时候就引入一个叫做拥塞窗口的概念。发送刚开始定义拥塞窗口为 1，每次收到ACK应答，拥塞窗口加 1。在发送数据之前，首先将拥塞窗口与接收端反馈的窗口大小比对，取较小的值作为实际发送的窗口。
拥塞窗口的增长是指数级别的。慢启动的机制只是说明在开始的时候发送的少，发送的慢，但是增长的速度是非常快的。为了控制拥塞窗口的增长，不能使拥塞窗口单纯的加倍，设置一个拥塞窗口的阈值，当拥塞窗口大小超过阈值时，不能再按照指数来增长，而是线性的增长。在慢启动开始的时候，慢启动的阈值等于窗口的最大值，一旦造成网络拥塞，发生超时重传时，慢启动的阈值会为原来的一半（这里的原来指的是发生网络拥塞时拥塞窗口的大小），同时拥塞窗口重置为 1。
拥塞控制是TCP在传输时尽可能快的将数据传输，并且避免拥塞造成的一系列问题。是可靠性的保证，同时也是维护了传输的高效性。