http请求到后台的整个流程

https://blog.csdn.net/kunlong0909/article/details/6765564/

1）浏览器查询 DNS，获取域名对应的IP地址:具体过程包括浏览器搜索自身的DNS缓存、搜索操作系统的DNS缓存、读取本地的Host文件和向本地DNS服务器进行查询等。对于向本地DNS服务器进行查询，如果要查询的域名包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析(此解析具有权威性)；如果要查询的域名不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析（此解析不具有权威性）。如果本地域名服务器并未缓存该网址映射关系，那么将根据其设置发起递归查询或者迭代查询；

2）浏览器获得域名对应的IP地址以后，浏览器向服务器请求建立链接，发起三次握手；

3）TCP/IP链接建立起来后，浏览器向服务器发送HTTP请求；

4）服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器；

5）浏览器解析并渲染视图，若遇到对js文件、css文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；

6）浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。

五层协议过程

1）客户端浏览器通过DNS解析到IP地址，通过这个IP地址找到客户端到服务器的路径。
客户端浏览器发起一个HTTP会话到该地址。

2）在传输层（端到端），把HTTP会话请求分成报文段，添加源和目的端口，然后通过TCP封装数据包，输入到网络层。该层解决差错控制，流量控制等。

3）网络层被打包，封装上网络层的包头，包头内部含有源及目的的ip地址，通过查找路由表确定如何到达服务器，期间可能经过多个路由器，这些都是由路由器来完成的工作。
查找到下一跳ip地址后，还需要知道它的mac地址，这个地址要作为链路层数据装进链路层头部。这时需要arp协议，具体过程是这样的：查找arp缓冲，如果里面含有对应ip的mac地址，则直接返回。否则需要发生arp请求，在网内进行广播，所有的主机会检查自己的ip与该请求中的目的ip是否一样，如果刚好对应则返回自己的mac地址，同时将请求者的ip mac保存。这样就得到了目标ip的mac地址。

4）链路层将mac地址及链路层控制信息加到数据包里，形成Frame，Frame在链路层协议下，完成了相邻的节点间的数据传输，完成连接建立，控制传输速度，数据完整。

5）物理线路则只负责该数据以bit为单位从主机传输到下一个目的地。

主要协议及作用：

OSI网络体系结构与TCP/IP协议模型

1）物理层
参考模型的最低层，也是OSI模型的第一层，实现了相邻计算机节点之间比特流的透明传送，并尽可能地屏蔽掉具体传输介质和物理设备的差异，使其上层(数据链路层)不必关心网络的具体传输介质

2）数据链路层
接收来自物理层的位流形式的数据，并封装成帧，传送到上一层；同样，也将来自上层的数据帧，拆装为位流形式的数据转发到物理层。这一层在物理层提供的比特流的基础上，通过差错控制、流量控制方法，使有差错的物理线路变为无差错的数据链路，即提供可靠的通过物理介质传输数据的方法。

3）网络层
将网络地址翻译成对应的物理地址，并通过路由选择算法为分组通过通信子网选择最适当的路径。

4）传输层
在源端与目的端之间提供可靠的透明数据传输，使上层服务用户不必关系通信子网的实现细节。在协议栈中，传输层位于网络层之上，传输层协议为不同主机上运行的进程提供逻辑通信，而网络层协议为不同主机提供逻辑通信，如下图所示。

5）会话层
会话层是OSI模型的第五层，是用户应用程序和网络之间的接口，负责在网络中的两节点之间建立、维持和终止通信。

6）表示层：数据的编码，压缩和解压缩，数据的加密和解密

7）应用层：为用户的应用进程提供网络通信服务

TCP和UDP分别对应的常见应用层协议

TCP对应的应用层协议

FTP：定义了文件传输协议，使用21端口。常说某某计算机开了FTP服务便是启动了文件传输服务。下载文件，上传主页，都要用到FTP服务。

Telnet：它是一种用于远程登陆的端口，用户可以以自己的身份远程连接到计算机上，通过这种端口可以提供一种基于DOS模式下的通信服务。如以前的BBS是-纯字符界面的，支持BBS的服务器将23端口打开，对外提供服务。

SMTP：定义了简单邮件传送协议，现在很多邮件服务器都用的是这个协议，用于发送邮件。如常见的免费邮件服务中用的就是这个邮件服务端口，所以在电子邮件设置-中常看到有这么SMTP端口设置这个栏，服务器开放的是25号端口。

POP3：它是和SMTP对应，POP3用于接收邮件。通常情况下，POP3协议所用的是110端口。也是说，只要你有相应的使用POP3协议的程序（例如Fo-xmail或Outlook），就可以不以Web方式登陆进邮箱界面，直接用邮件程序就可以收到邮件（如是163邮箱就没有必要先进入网易网站，再进入自己的邮-箱来收信）。

HTTP：从Web服务器传输超文本到本地浏览器的传送协议。

UDP对应的应用层协议

DNS：用于域名解析服务，将域名地址转换为IP地址。DNS用的是53号端口。

SNMP：简单网络管理协议，使用161号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。

TFTP(Trival File Transfer Protocal)：简单文件传输协议，该协议在熟知端口69上使用UDP服务。

HTTP1.1与HTTP1.0

Http1.1 比 Http1.0 多了以下优点：

1. 引入持久连接，即 在同一个TCP的连接中可传送多个HTTP请求 & 响应
2. 多个请求 & 响应可同时进行、可重叠
3. 引入更加多的请求头 & 响应头

HTTP与HTTPS

HTTP协议运行在TCP之上，明文传输，客户端与服务器端都无法验证对方的身份；HTTPS是身披SSL(Secure Socket Layer)外壳的HTTP，运行于SSL上，SSL运行于TCP之上。
HTTP加上信息加密、身份认证以及完整性校验后即是HTTPS。
其利用对称加密算法采用协商的密钥对数据加密，非对称加密实现身份认证和密钥协商，基于散列函数验证信息的完整性。

参考：
1、为什么HTTPS比HTTP更安全
https://blog.csdn.net/howgod/article/details/89596638
2、谈谈 HTTPS
https://juejin.im/post/59e4c02151882578d02f4aca

• 1.信息加密–对称加密与非对称加密

对称加密是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方；而非对称加密是指使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。
由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性；但是和对称加密比起来，它非常的慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。在交换密钥环节使用非对称加密方式，之后的建立通信交换报文阶段则使用对称加密方式。(HTTPS采用这种方式)

• 中间人攻击

  在使用非对称密钥的时候，中间人可以拦截到公钥，就可以对拦截到的公钥进行篡改。即需要确认，公钥是来自于接收方而不是中间人的。需要一个公证处，即证书颁发机构（Certificate Authority，简称CA）。

• 2.完整性校验–数字签名

网络传输过程中需要经过很多中间节点，虽然数据无法被解密，但可能被篡改，那如何校验数据的完整性呢？----校验数字签名。

数字签名有两种功效：

• 能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。
• 数字签名能确定消息的完整性,证明数据是否未被篡改过。

工作原理：
1.将一段文本先用Hash函数生成消息摘要，然后用发送者的私钥加密生成数字签名，与原文文一起传送给接收者。

2.接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与上一步得到的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。

问题的关键的是，和消息本身一样，公钥不能在不安全的网络中直接发送给接收方, 或者说拿到的公钥如何证明是发送方的。
此时就需要引入了证书颁发机构（Certificate Authority，简称CA），CA数量并不多，Kobe客户端内置了所有受信任CA的证书。CA对发送方的公钥（和其他信息）数字签名后生成证书。

• 3.身份认证–CA

在拿到数字证书之后，就用同样的Hash 算法， 再次生成消息摘要，然后用CA的公钥对数字签名解密， 得到CA创建的消息摘要， 两者一比，就知道有没有人篡改了。

HTTPS工作流程

1.Client发起一个HTTPS（比如 https://juejin.im/user）的请求，根据RFC2818的规定，Client知道需要连接Server的443（默认）端口。

2.Server把事先配置好的公钥证书（public key certificate）返回给客户端。

3.Client验证公钥证书：比如是否在有效期内，证书的用途是不是匹配Client请求的站点，是不是在CRL吊销列表里面，它的上一级证书是否有效，这是一个递归的过程，直到验证到根证书（操作系统内置的Root证书或者Client内置的Root证书）。如果验证通过则继续，不通过则显示警告信息。

4.Client使用伪随机数生成器生成加密所使用的对称密钥，然后用证书的公钥加密这个对称密钥，发给Server。

5.Server使用自己的私钥（private key）解密这个消息，得到对称密钥。至此，Client和Server双方都持有了相同的对称密钥。

6.Server使用对称密钥加密“明文内容A”，发送给Client。

7.Client使用对称密钥解密响应的密文，得到“明文内容A”。

8.Client再次发起HTTPS的请求，使用对称密钥加密请求的“明文内容B”，然后Server使用对称密钥解密密文，得到“明文内容B”。

HTTP常见状态码

2XX 成功

200 OK：最常见的就是正常情况下的200，表示从客户端发来的请求被服务器端正常处理了；

204 No Content：表示服务器已经成功接收并处理了客户端的请求，但在返回报文中不存在实体内容部分，一般这类请求就是单方面的向服务器发送信息，并不需要得到返回数据，类似于单相思-。-

3XX 重定向

301 Moved Permanently：永久性重定向。表示请求的资源被分配了新的URL，以后应使用资源现在所指的URL。简单的说就是你背下了一个网站地址，也可能是保存到了收藏夹里，但突然某一天，这个网站的域名换了，你再去点击这个收藏夹，响应报文中就会出现这个状态码，告诉你这个地址已经被永久性重定向到另一个地址了，一般来说浏览器地址栏的URL会切换到新的URL；

302 Found：临时重定向。表示请求的资源被分配了新的URL，希望用户（本次）能使用新的URL访问；跟上面301的区别就是，浏览器对此次的请求不会跳转到新的URL上，还是显示你所输入的URL，但网页内容是新URL的内容，表示这只是临时的重定向。这就造成了可能出现URL劫持的情况发生；

4XX 客户端错误

403 Forbidden：未获得访问权限。表示客户端对请求资源的访问被服务器拒绝了，例如客户端的IP地址不在服务器端的允许访问白名单中；

404 Not Found：没有找到资源对象。被很多程序猿吐槽为找不到对象，一般来说要检查下是否是URL地址输错了。另外如果服务器端拒绝了你的请求且不想说明原因的时候也可以返回这个状态码；

5XX服务器错误

500 Internal Server Error：500错误出现的原因有很多，但归根结底都是服务器内部错误，可能是服务器环境出错了；

502 Bad Gateway：服务器网关错误，出现这个错误的原因往往跟网络请求有关，服务器正在承受过载的网络请求，导致你的请求超时了。客户端可以尝试清除缓存刷新重新请求，如果继续报错502，则需要程序猿优化下网络请求比如升级带宽或负载均衡等，或者检查是否出现了大量的恶意访问；

503 Service Unavailable：服务不可用。表示服务器暂时不可用或者CPU超负荷了，导致请求无法被处理。如果不是停机维护的话，你就需要检查下是否是服务器遭到了DDoS攻击了，或者是程序没写好导致占用了过多的php线程，这时候你就需要优化下程序了；

504 Gateway Timeout：网关超时。简单的说就是请求超时了，原因可能有很多，但一般来说这种情况都是临时的，最简单粗暴的理解就是服务器端…网速差…如果频繁出现这个问题，这时候程序猿可能需要去联系一下服务器供应商解决这个问题。

cookies和session

会话：
用户开一个浏览器，点击多个超链接，访问服务器多个web资源，然后关闭浏览器，整个过程称之为一个会话。
每个用户在使用浏览器与服务器进行会话的过程中，不可避免各自会产生一些数据，程序要想办法为每个用户保存这些数据，cookies和session是保存会话数据的两种方式。

Cookie和Session都是客户端与服务器之间保持状态的解决方案，具体来说，cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。

区别：保存在客户端/服务端，数据大小，安全性，性能。

cookie

（1）Cookie的数据保存在客户端。
（2）Cookie中只能存放少量的数据，数据大小和数量方面都有限制。
（3）Cookie机制不是很安全，我们可以分析存放在本地的Cookie从而进行Cookie欺骗。因此，Cookie中最好不存放一些敏感的信息。
（4）Cookie的过期时间：如果不设置Cookie的过期时间，则将当前Cookie称为会话Cookie，表示这个Cookie的生命期为浏览器的会话期间，关闭浏览器窗口，Cookie就消失了，会话Cookie一般保存在内存里。设置了过期时间，则将当前Cookie称为持久Cookie，浏览器会把Cookie保存在硬盘上，存储在硬盘上的Cookie会在不同的浏览器进程间共享。

session

（1）Session的数据保存在服务器端，准确的来说是保存在服务器端的内存中，当服务器重启后，Session就会消失。
（2）Session没有大小的限制，Session保存的数据由服务器的内存决定，内存越大，保存的Session就越多。
（3）但我们过量的使用Session时，会占据大量内存，大大降低服务器的性能。为了防止Session过多造成的内存溢出，我们会对Session设置超时时间，如果在这个时间内，用户没有继续访问过网站，服务器就会在内存中将这个Session剔除掉。

https://blog.csdn.net/qq_33591903/article/details/82714787

TCP/UDP

作为一个面向连接的传输层协议，TCP的目标是为用户提供可靠的端到端连接，保证信息有序无误的传输。它除了提供基本的数据传输功能外，还为保证可靠性采用了数据编号、校验和计算、数据确认等一系列措施。它对传送的每个数据字节都进行编号，并请求接收方回传确认信息（ACK）。发送方如果在规定的时间内没有收到数据确认，就重传该数据。

（1）数据编号使接收方能够处理数据的失序和重复问题。
（2）数据误码问题通过在每个传输的数据段中增加校验和予以解决，接收方在接收到数据后检查校验和，若校验和有误，则丢弃该有误码的数据段，并要求发送方重传。
（3） 流量控制也是保证可靠性的一个重要措施，若无流控，可能会因接收缓冲区溢出而丢失大量数据，导致许多重传，造成网络拥塞恶性循环。
（4）TCP采用可变窗口进行流量控制，由接收方控制发送方发送的数据量。
TCP为用户提供了高可靠性的网络传输服务，但可靠性保障措施也影响了传输效率。因此，在实际工程应用中，只有关键数据的传输才采用TCP，而普通数据的传输一般采用高效率的UDP。

TCP协议如何来保证传输的可靠性

TCP提供一种面向连接的、可靠的字节流服务。其中，面向连接意味着两个使用TCP的应用（通常是一个客户和一个服务器）在彼此交换数据之前必须先建立一个TCP连接。在一个TCP连接中，仅有两方进行彼此通信；而字节流服务意味着两个应用程序通过TCP链接交换8bit字节构成的字节流，TCP不在字节流中插入记录标识符。

对于可靠性，TCP通过以下方式进行保证：

数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时TCP发送数据端超时后会重发数据；

对失序数据包重排序：既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。TCP将对失序数据进行重新排序，然后才交给应用层；

丢弃重复数据：对于重复数据，能够丢弃重复数据；

应答机制：当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒；

超时重发：当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；

流量控制：TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP使用的流量控制协议是可变大小的滑动窗口协议。

TCP与UDP的区别

TCP (Transmission Control Protocol)和UDP(User Datagram Protocol)协议属于传输层协议，它们之间的区别包括：

1）TCP是面向连接的，UDP是无连接的；

2）TCP是可靠的，UDP是不可靠的；

3）TCP是面向字节流的，UDP是面向报文的；

4）TCP有拥塞控制机制;UDP没有拥塞控制，适合媒体通信；

5）TCP只支持点对点通信，UDP支持一对一、一对多、多对一、多对多的通信模式；

6）TCP首部开销(20个字节)比UDP的首部开销(8个字节)要大；

TCP特性

1.可靠性
Reliability，TCP提供数据传的可靠性，确保接收端是否已接收到数据，如果超时没有收到接收端的确认，则会重新传输。
2.流控的
Data Flow Control，TCP还提供数据传输的流控，有一个缓冲区接管，不能传输任意大的数据量，这就由滑动窗口来实现这个特性。

TCP拆包 粘包

UDP是基于报文发送的，UDP报文的首部会有16bit来表现UDP数据的长度，所以不同的报文之间是可以区别隔离出来的，所以应用层接收传输层的报文时，不会存在拆包和粘包的问题；
而TCP是基于字节流传的，应用层和传输层之前数据交互是大小不等的数据块，但TCP对这些数据块只是一连串的数据流，它并不知道哪些数据块跟哪些数据块是该一起发，哪个数据块是应该单独一块的，因为TCP并没有像UDP那样首部有数据长度，所以TCP存在拆包和粘包的问题。
原因：
1.要发送的数据包大于发送缓存区的可用空间时，数据被会拆包；
2.要发送的数据大于MSS（Maximum Segment Size最大报文段），TCP在发送前会对数据进行拆包；
TCP在三次握手建立连接过程中，会在SYN报文中使用MSS选项功能，协商交互双方能够接收的最大段长MSS值。
MSS是传输层TCP协议范畴内的概念，它是标识TCP能够承载的最大的应用数据段长度，因此，MSS=MTU-20字节TCP报头-20字节IP报头，那么在以太网环境下，MSS值一般就是1500-20-20=1460字节。
3.发送的数据小于缓存区，则TCP会将几次的数据一次性发送，会存在粘包。
解决：
由于TCP是不知道应用层的数据包的分界的，所以我们应用层是决定不了传输层对数据包拆包还是粘包，不过应用层可以通应用层协议栈设计给数据包加分界标记，来处理最后接收到的数据，不管拆分还是粘包都可以处理好。

1.发送端给数据包增加首部，首部包含数据包中数据的长度，这样接收端的应用层接收数据后，根据首部中的长度就知道数据的实际长度了，可以很好处理数据了。
通常设计思路，比如第1个字段使用32int表示数据的长度，接着是数据内容。
2.设置数据包的长度为固定的长度，不够数据则以空格填补；
3.应用层在发送每个数据包时，给每个数据包加分界标记，比如回车换行。

在接收端接收的数据包个数总比发送端发送的个数少时，那是发送端的发送速度过快，导致接收端接收不过来，接收端会告知发送端的发送窗口为0，发送端新来数据只能暂存在发送缓存区中，当发送缓存区溢出后，则会出现丢包，可以增大发送缓存区来缓解，就是拥堵问题。

UDP丢包 无序

UDP是无连接的，面向消息的数据传输协议，与TCP相比，有两个致命的缺点，一是数据包容易丢失，二是数据包无序。
丢包原因：
1.客户端发送过快，网络状况不好或者超过服务器接收速度，就会丢包。
2.接收端处理时间过长导致丢包: 调用recv方法接收端收到数据后，处理数据花了一些时间，处理完后再次调用recv方法，在这二次调用间隔里,发过来的包可能丢失。
3.发送的包较大，超过接受者缓存导致丢包:包超过mtu size数倍，几个大的udp包可能会超过接收者的缓冲，导致丢包。
解决方法：
1.客户端降低发送速度，可以等待回包，或者加一些延迟(sleep)。
2.服务器部分单独开一个线程，去接收UDP数据，存放在一个缓冲区中，迅速返回继续recv去处理收到的数据，尽量减少因为处理数据延时造成的丢包。
3.设置socket接收缓冲。用setsockopt()将接收缓存(SO_RCVBUF)加大
要实现文件的可靠传输，就必须在上层对数据丢包和乱序作特殊处理，必须要有要有丢包重发机制和超时机制。
常见的可靠传输算法有模拟TCP协议，重发请求（ARQ）协议，它又可分为连续ARQ协议、选择重发ARQ协议、滑动窗口协议等等。

窗口控制与重发控制

每发送一个段就进行一次确认，那么包的往返时间越长，网络的吞吐量量就会越差，通信性能就会越低。
为了解决这个问题，TCP引入了窗口的概念。确认应答不再是以每个片段，而是以更大的单位（窗口大小）进行确认，转发时间就被大幅度的缩短。至于窗口的大小是由接收端主机决定的，也方便进行流控制。
使用窗口控制之后，可以收到确认应答之前继续发送报文，这样整体速度就大大提高。
针对确认应答未能返回的情况。没有使用窗口控制的时候，没有收到确认应答的数据都会被重发，而使用了窗口控制，某些确认应答即便丢失也无需重发。可以根据自己的确认应答或者下一个确认应答来确认。
对于发送端，如果连续三次收到同一个确认应答，将会对其对应的数据进行重发。

TCP拥塞控制

计算机网络中的带宽、交换结点中的缓存及处理机等都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就会变坏，这种情况就叫做拥塞。拥塞控制就是 防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致过载。注意，拥塞控制和流量控制不同，前者是一个全局性的过程，而后者指点对点通信量的控制。

拥塞窗口（cwnd）：TCP拥塞控制中的主要参数，表示发送端下一次最多可以发送的数据分包的个数，是来自发送端的流量控制。

接收端窗口（rwnd）：又称通知窗口（Advertise Window），接受端目前每次所能接收的数据分组的最大个数，是来自接收端的流量控制。

慢开始门限（ssthresh）：当拥塞窗口增长到慢开始门限时，启动拥塞避免算法。

拥塞控制常用算法：慢开始、拥塞避免、快重传、快恢复。

慢开始：
1、初始拥塞窗口为 1
2、每接收一个报文确认后，cwnd 翻倍
3、cwnd 呈指数型增长，到达慢开始门限（ssthresh）后，改用拥塞避免算法

拥塞避免：
1、cwnd 每经过一个报文确认（往返时间）就增加 1，线性增长
2、当出现依次超时，令 ssthresh 为 cwnd 的一半，cwnd 重新置为 1

cwnd 不同时执行的算法：
cwnd < ssthresh ：慢开始
cwnd > ssthresh ：拥塞控制

1. 初始时，cwnd 被设置为 1，并且开始慢开始算法（成倍增加）
2. 当 cwnd 增长到慢开始门限 ssthresh （cwnd = 16）时，改用拥塞避免算法
3. 由图可知，当 cwnd 到达 24 时，发生网络拥塞，ssthresh 变为 cwnd 的一半，也就是 ssthresh = 12，然后 cwnd 置为 1

PS：若在慢开始算法时，翻倍后的 cwnd > ssthresh ，cwnd 只能等于 ssthresh 而不能超过它

快重传和快恢复

1、当发送方收到了 3 个 ACK 报文（失序的报文段 ），ssthresh 设置为 cwnd 的一半，然后 cwnd 置为当前 ssthresh 的值（而不是在拥塞控制算法中的 cwnd 置为 1）
2、接着采用拥塞避免的加法线性增大

三次握手

三次握手（Three-way Handshake）其实就是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。进行三次握手的主要作用就是为了确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备。实质上其实就是连接服务器指定端口，建立TCP连接，并同步连接双方的序列号和确认号，交换TCP窗口大小信息。

三次握手(我要和你建立链接，你真的要和我建立链接么，我真的要和你建立链接，成功)：

第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。

第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。

第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。

四次挥手(我要和你断开链接；好的，断吧。我也要和你断开链接；好的，断吧)：

第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。

第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。此时TCP链接处于半关闭状态，即客户端已经没有要发送的数据了，但服务端若发送数据，则客户端仍要接收。
客户端收到服务端的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。

第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。

第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态。接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。

2MSL等待的另一个结果是这个TCP连接在2MSL等待期间，定义这个连接的插口（客户的IP地址和端口号，服务器的IP地址和端口号）不能再被使用。这个连接只能在2MSL结束后才能再被使用。

在socket编程中，任何一方执行close()操作即可产生挥手操作。

为什么采用三次握手而不是二次握手

为了防止 已失效的链接请求报文突然又传送到了服务端，因而产生错误。
client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。

TCP三次握手时，第三次握手失败怎么办

当第三次握手失败时，服务器并不会重传ACK报文，而是直接发送RTS报文段，进入CLOSED状态。这样做的目的是为了防止SYN洪泛攻击。

SYN洪泛攻击

服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。SYN 攻击是一种典型的 DoS/DDoS 攻击。

检测 SYN 攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击。在 Linux/Unix 上可以使用系统自带的 netstats 命令来检测 SYN 攻击。

netstat -n -p TCP | grep SYN_RECV

常见的防御 SYN 攻击的方法有如下几种：

• 缩短超时（SYN Timeout）时间
• 增加最大半连接数
• 过滤网关防护
• SYN cookies技术

什么是半连接队列？

服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。
当然还有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

这里在补充一点关于SYN-ACK 重传次数的问题：

服务器发送完SYN-ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传。如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。
注意，每次重传等待的时间不一定相同，一般会是指数增长，例如间隔时间为 1s，2s，4s，8s…

ISN(Initial Sequence Number)是固定的吗？

当一端为建立连接而发送它的SYN时，它为连接选择一个初始序号。ISN随时间而变化，因此每个连接都将具有不同的ISN。ISN可以看作是一个32比特的计数器，每4ms加1 。这样选择序号的目的在于防止在网络中被延迟的分组在以后又被传送，而导致某个连接的一方对它做错误的解释。

三次握手的其中一个重要功能是客户端和服务端交换 ISN(Initial Sequence Number)，以便让对方知道接下来接收数据的时候如何按序列号组装数据。如果 ISN 是固定的，攻击者很容易猜出后续的确认号，因此 ISN 是动态生成的。

三次握手过程中可以携带数据吗？

第三次握手的时候，是可以携带数据的。但是，第一次、第二次握手不可以携带数据。

当关闭连接时最后一个ACK丢失怎么办

如果最后一个ACK丢失的话，TCP就会认为它的FIN丢失，进行重发FIN。在客户端收到FIN后，就会设置一个2MSL计时器，2MSL计时器可以使客户等待足够长的时间，使得在ACK丢失的情况下，可以等到下一个FIN的到来。如果在TIME－WAIT状态汇总有一个新的FIN到达了，客户就会发送一个新的ACK，并重新设置2MSL计时器。

客户端不断进行请求链接会怎样？

DDos(Distributed Denial of Service)攻击
1）客户端向服务端发送请求链接数据包
2）服务端向客户端发送确认数据包
3）客户端不向服务端发送确认数据包，服务器一直等待来自客户端的确认

DDos 预防 ( 没有彻底根治的办法，除非不使用TCP )
1）限制同时打开SYN半链接的数目
2）缩短SYN半链接的Time out 时间
3）关闭不必要的服务

为什么要TIME_WAIT状态保持2倍MSL(最大数据段生存期)的时间而不是直接进入CLOSED状态？

原因：
1、保证TCP协议的全双工连接能够可靠关闭
2、保证这次连接的重复数据段从网络中消失

先说第一点，如果Client直接CLOSED了，那么由于IP协议的不可靠性或者是其它网络原因，导致Server没有收到Client最后回复的ACK。那么Server就会在超时之后继续发送FIN，此时由于Client已经CLOSED了，就找不到与重发的FIN对应的连接，所以客户端不会再发送一次确认报文段，则服务端无法正常进入到CLOSED状态。
最后Server就会收到RST而不是ACK，Server就会以为是连接错误把问题报告给高层。这样的情况虽然不会造成数据丢失，但是却导致TCP协议不符合可靠连接的要求。所以，Client不是直接进入CLOSED，而是要保持TIME_WAIT，当再次收到FIN的时候，能够保证对方收到ACK，最后正确的关闭连接。

再说第二点，如果Client直接CLOSED，然后又再向Server发起一个新连接，我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题，但是还是有特殊情况出现：假设新连接和已经关闭的老连接端口号是一样的，如果前一次连接的某些数据仍然滞留在网络中，这些延迟数据在建立新连接之后才到达Server，由于新连接和老连接的端口号是一样的，又因为TCP协议判断不同连接的依据是socket pair，于是，TCP协议就认为那个延迟的数据是属于新连接的，这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2倍MSL，这样可以保证本次连接的所有数据都从网络中消失。

CLOSE_WAIT和TIME_WAIT过多

查看主机tcp状态
netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’

CLOSE_WAIT过多

• 原因
  程序写的有问题，没有合适的关闭socket；
  服务端socket忙于读写；

• 解决方法
  CLOSE_WAIT需要通过程序本身。
  如果一直保持在CLOSE_WAIT状态，那么只有一种情况，就是在对方关闭连接之后服务器程序自己没有进一步发出ack信号。即在对方连接关闭之后，程序里没有检测到，或者程序没有关闭连接，于是这个资源就一直被程序占着。
  服务器对于程序抢占的资源没有主动回收的功能。只能修改程序本身。
  1）使用完socket调用close方法；
  2）socket读控制，当读取的长度为0时（读到结尾），立即close；
  3）如果read返回-1，出现错误，检查error返回码，如果不是AGAIN，立即close；有三种情况：INTR（被中断，可以继续读取），WOULDBLOCK（表示当前socket_fd文件描述符是非阻塞的，但是现在被阻塞了），AGAIN（表示现在没有数据稍后重新读取）。

TIME_WAIT过多

• 原因
  大量的短连接服务；
  就是对方连接的异常；
  没有迅速回收资源；

• 解决方法
  TIME_WAIT状态可以通过优化服务器参数得到解决，因为发生TIME_WAIT的情况是服务器自身可控的。
  调整TIME_WAIT超时时间：
  vi /etc/sysctl.conf
  #表示开启SYN Cookies。
  #当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭
  net.ipv4.tcp_syncookies = 1
  #表示开启重用。
  #允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭
  net.ipv4.tcp_tw_reuse = 1
  #表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭
  net.ipv4.tcp_tw_recycle = 1
  #表示如果套接字由本端要求关闭。
  #这个参数决定了它保持在FIN-WAIT-2状态的时间
  #生效，如下命令
  /sbin/sysctl -p

1）随机端口使用完，你可以通过调整/etc/sysctl.conf下的net.ipv4.ip_local_port_range配置，至少修改成 net.ipv4.ip_local_port_range=1024 65535，保证你的负载均衡服务器至少可以使用6万个随机端口，也即可以有6万的反向代理到后端的连接，可以支持每秒1000的并发（想一想，因为TIME_WAIT状态会持续1分钟后消失，所以一分钟最多有6万，每秒1000）；如果这么多端口都使用完了，也证明你应该加服务器了，或者，你的负载均衡服务器需要配置多个IP地址，或者，你的后端服务器需要监听更多的端口和配置更多的IP（想一下socket的五元组）

2）大量的TIME_WAIT，多大量？如果是几千个，其实不用担心，因为这个内存和CPU的消耗有一些，但是是可以忽略的。如果真的量很大，上万上万的那种，可以考虑，让后端的服务器主动关闭连接，如果后端服务器没有外网的连接只有负载均衡服务器的连接（主要是没有NAT网络的连接），可以在后端服务器上配置tw_recycle，然后同时，在负载均衡服务器上，配置tw_reuse。

参考文章：
https://www.jianshu.com/p/44655bff60a4

urllib和urllib2的区别

urllib提供urlencode方法用来GET查询字符串的产生，而urllib2没有。这是为何urllib常和urllib2一起使用的原因。
urllib2可以接受一个Request类的实例来设置URL请求的headers，urllib仅可以接受URL。这意味着，你不可以伪装你的User Agent字符串等。

Get与POST的区别

GET与POST是我们常用的两种HTTP Method，二者之间的区别主要包括如下五个方面：

(1). 从功能上讲，GET一般用来从服务器上获取资源，POST一般用来更新服务器上的资源；

(2). 从REST服务角度上说，GET是幂等的，即读取同一个资源，总是得到相同的数据，而POST不是幂等的，因为每次请求对资源的改变并不是相同的；进一步地，GET不会改变服务器上的资源，而POST会对服务器资源进行改变；

(3). 从请求参数形式上看，GET请求的数据会附在URL之后，即将请求数据放置在HTTP报文的 请求头中，以?分割URL和传输数据，参数之间以&相连。特别地，如果数据是英文字母/数字，原样发送；否则，会将其编码为 application/x-www-form-urlencoded MIME 字符串(如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII)；而POST请求会把提交的数据则放置在是HTTP请求报文的 请求体 中。

(4). 就安全性而言，POST的安全性要比GET的安全性高，因为GET请求提交的数据将明文出现在URL上，而且POST请求参数则被包装到请求体中，相对更安全。

(5). 从请求的大小看，GET请求的长度受限于浏览器或服务器对URL长度的限制，允许发送的数据量比较小，而POST请求则是没有大小限制的。

SQL注入和XSS 攻击

SQL注入就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。

SQL注入攻击的总体思路
　　(1). 寻找到SQL注入的位置
　　(2). 判断服务器类型和后台数据库类型
　　(3). 针对不通的服务器和数据库特点进行SQL注入攻击

应对方法：

• 1）参数绑定

  • 使用预编译手段，绑定参数是最好的防SQL注入的方法。目前许多的ORM框架及JDBC等都实现了SQL预编译和参数绑定功能，攻击者的恶意SQL会被当做SQL的参数而不是SQL命令被执行。在mybatis的mapper文件中，对于传递的参数我们一般是使用#和KaTeX parse error: Expected 'EOF', got '#' at position 11: 来获取参数值。当使用#̲时，变量是占位符，就是一般我们…时，变量就是直接追加在sql中，一般会有sql注入问题。

• 2）使用正则表达式过滤传入的参数

XSS

是一种经常出现在web应用中的计算机安全漏洞，与SQL注入一起成为web中最主流的攻击方式。XSS是指恶意攻击者利用网站没有对用户提交数据进行转义处理或者过滤不足的缺点，进而添加一些脚本代码嵌入到web页面中去，使别的用户访问都会执行相应的嵌入代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。

主要原因：过于信任客户端提交的数据！

解决办法：不信任任何客户端提交的数据，只要是客户端提交的数据就应该先进行相应的过滤处理然后方可进行下一步的操作。

TCP状态变迁图

如下图所示，粗的实线箭头表示正常的客户端状态变迁，粗的虚线箭头表示正常的服务器状态变迁。

本文参考文章：

1. TCP协议-滑动窗口、拆包和粘包
   https://blog.csdn.net/jjavaboy/article/details/80037057

2. TCP粘包问题分析和解决（全）
   https://blog.csdn.net/wojiuguowei/article/details/85326958

3. 三次握手 四次挥手
   https://www.cnblogs.com/Jessy/p/3535612.html

4. 计算机网络中的TCP/UDP协议到底是怎么回事:
   https://www.jianshu.com/p/8be9b3204864

5. TCP拥塞控制: https://www.jianshu.com/p/eab86c0d1612

6. https://blog.csdn.net/justloveyou_/article/details/78303617

7. https://juejin.im/post/5d9c284b518825095879e7a5（推荐）

最后

以上就是无心中心为你收集整理的相关知识点-计算机网络http请求到后台的整个流程OSI网络体系结构与TCP/IP协议模型TCP和UDP分别对应的常见应用层协议HTTP1.1与HTTP1.0HTTP与HTTPSTCP/UDPTCP与UDP的区别三次握手urllib和urllib2的区别Get与POST的区别SQL注入和XSS 攻击的全部内容，希望文章能够帮你解决相关知识点-计算机网络http请求到后台的整个流程OSI网络体系结构与TCP/IP协议模型TCP和UDP分别对应的常见应用层协议HTTP1.1与HTTP1.0HTTP与HTTPSTCP/UDPTCP与UDP的区别三次握手urllib和urllib2的区别Get与POST的区别SQL注入和XSS 攻击所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。