网络知识点Session在服务器上储存用户信息.Session 的工作机制是：为每个访客创建一个唯一的 id (UID)

网络知识点

Session 和 cookie的区别

Session在服务器上储存用户信息.Session 的工作机制是：为每个访客创建一个唯一的 id (UID)，并基于这个 UID 来存储变量。
Cookie是服务器在本地机器上存储的小段文本并随每一个请求发送至同一个服务器。网络服务器用HTTP头向客户端发送cookies，在客户终端，浏览器解析这些cookies并将它们保存为一个本地文件，它会自动在符合要求的请求中添加上这些cookies 。cookie的作用就是为了解决HTTP协议无状态的缺陷。区别

类型	Session	Cookie
安全性	储存服务器上，Session里数据的安全性可以得到有效的保护	Cookie储存在客服端中,对用户是可见的,敏感信息要加密
有效时间	由于PHPSESSID未设置过期时期当关闭浏览器Seesion就会失效	设置过期时间到指定的过期时间,未设置时关闭就失效
服务器压力	耗费服务器大量的内存	储存在客服端对服务器无压力

HTTP报文格式

HTTP报文是面向文本的，报文中的每一个字段都是一些ASCII码串，各个字段的长度是不确定的。HTTP有两类报文：请求报文和响应报文。
HTTP请求报文
一个HTTP请求报文由请求行（request line）、请求头部（header）、空行和请求数据4个部分组成，下图给出了请求报文的一般格式。

HTTP响应报文
HTTP响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文。

* Rebuilt URL to: www.baidu.com/
*   Trying 110.242.68.3...
* TCP_NODELAY set
* Connected to www.baidu.com (110.242.68.3) port 80 (#0)
> GET / HTTP/1.1
> Host: www.baidu.com
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform
< Connection: keep-alive
< Content-Length: 2381
< Content-Type: text/html
< Date: Sun, 28 Feb 2021 13:56:48 GMT
< Etag: "588604c1-94d"
< Last-Modified: Mon, 23 Jan 2017 13:27:29 GMT
< Pragma: no-cache
< Server: bfe/1.0.8.18
< Set-Cookie: BDORZ=27315; max-age=86400; domain=.baidu.com; path=/
<
<!DOCTYPE html>
<!--STATUS OK--><html> <head><meta http-equiv=content-type content=text/html;charset=utf-8><meta http-equiv=X-UA-Compatible content=IE=Edge><meta content=always name=referrer><link rel=stylesheet type=text/css href=http://s1.bdstatic.com/r/www/cache/bdorz/baidu.min.css><title>百度一下，你就知道</title></head> <body link=#0000cc> <div id=wrapper> <div id=head> <div class=head_wrapper> <div class=s_form> <div class=s_form_wrapper> <div id=lg> <img hidefocus=true src=//www.baidu.com/img/bd_logo1.png width=270 height=129> </div> <form id=form name=f action=//www.baidu.com/s class=fm> <input type=hidden name=bdorz_come value=1> <input type=hidden name=ie value=utf-8> <input type=hidden name=f value=8> <input type=hidden name=rsv_bp value=1> <input type=hidden name=rsv_idx value=1> <input type=hidden name=tn value=baidu><span class="bg s_ipt_wr"><input id=kw name=wd class=s_ipt value maxlength=255 autocomplete=off autofocus></span><span class="bg s_btn_wr"><input type=submit id=su value=百度一下 class="bg s_btn"></span> </form> </div> </div> <div id=u1> <a href=http://news.baidu.com name=tj_trnews class=mnav>新闻</a> <a href=http://www.hao123.com name=tj_trhao123 class=mnav>hao123</a> <a href=http://map.baidu.com name=tj_trmap class=mnav>地图</a> <a href=http://v.baidu.com name=tj_trvideo class=mnav>视频</a> <a href=http://tieba.baidu.com name=tj_trtieba class=mnav>贴吧</a> <noscript> <a href=http://www.baidu.com/bdorz/login.gif?login&amp;tpl=mn&amp;u=http%3A%2F%2Fwww.baidu.com%2f%3fbdorz_come%3d1 name=tj_login class=lb>登录</a> </noscript> <script>document.write('<a href="http://www.baidu.com/bdorz/login.gif?login&tpl=mn&u='+ encodeURIComponent(window.location.href+ (window.location.search === "" ? "?" : "&")+ "bdorz_come=1")+ '" name="tj_login" class="lb">登录</a>');</script> <a href=//www.baidu.com/more/ name=tj_briicon class=bri style="display: block;">更多产品</a> </div> </div> </div> <div id=ftCon> <div id=ftConw> <p id=lh> <a href=http://home.baidu.com>关于百度</a> <a href=http://ir.baidu.com>About Baidu</a> </p> <p id=cp>&copy;2017&nbsp;Baidu&nbsp;<a href=http://www.baidu.com/duty/>使用百度前必读</a>&nbsp; <a href=http://jianyi.baidu.com/ class=cp-feedback>意见反馈</a>&nbsp;京ICP证030173号&nbsp; <img src=//www.baidu.com/img/gs.gif> </p> </div> </div> </div> </body> </html>

HTTP 头部字段

字段	描述
`Host`	指定请求的目标主机名
`User-Agent`	标识客户端的应用程序类型、操作系统、软件版本等信息
`Accept`	指定客户端能够接收的响应内容类型
`Accept-Encoding`	指定客户端支持的内容编码类型
`Referer`	表示请求的来源页面 URL
`Cookie`	客户端发送到服务器的一个或多个 cookie
`Content-Type`	表示响应的媒体类型（MIME 类型）
`Content-Length`	表示响应体的字节长度
`Set-Cookie`	用于从服务器向客户端发送一个 cookie
`Cache-Control`	指示响应的缓存机制
`Location`	指示客户端应重定向到的 URL
`Content-Encoding`	指示对实体主体应用的编码（压缩）方式
`Content-Language`	指示实体主体的语言
`Last-Modified`	指示实体主体最后修改的日期和时间
`Expires`	指示实体主体的过期时间

Keep-Alive是否使用，解释其作用

HTTP协议的基本特点是"一来一回".客户端发起一个TCP连接,在连接上面发一个HTTP Request到服务器,服务器返回一个HTTP Response,然后连接关闭.每一个请求,就要开一个连接,请求完了,连接关闭.
这连接的建立,关闭都是耗时操作会带来性能问题.
HTTP1.0设计了一个Keep-Alive机制来实现TCP的复用.
实现 : 在HTTP请求头部添加Connection: keep-alive

TCP复用

TCP复用（TCP Multiplexing）通常指的是在一台主机上，可以使用同一个IP地址和端口号，支持多个不同的TCP连接并存的能力，核心是利用了“五元组”来唯一标识一个TCP连接：五元组指的是用来唯一标识一个TCP连接的五个要素，具体为：

源 IP 地址（Source IP Address）源端口号（Source Port）目标 IP 地址（Destination IP Address）目标端口号（Destination Port）传输层协议类型（Protocol），通常为TCP或UDP

多路复用（Multiplexing）：比如 HTTP/2 通过一个TCP连接“复用”多条逻辑流

TCP三次握手/四次挥手

HTTP连接&关闭.jpeg

TCP连接三次握手

第一次握手：客户端发送连接请求报文段，将SYN标志位设置成1，序列号seq=x；然后，客户端进入SYN_SEND状态，等待服务器的确认；
第二次握手：服务端收到客户端发过来的报文后，发现SYN=1，知道这是一个连接请求。服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，服务器端将标志位SYN和ACK都置为1，ack=x+1，随机产生一个值seq=y，并将该数据包发送给客户端以确认连接请求，服务器端进入SYN_RCVD状态。
第三次握手：客户端收到服务器的SYN+ACK报文段。然后将确认号ack设置为y+1，向服务器发送ACK报文段，服务器端检查ack是否为y+1，ACK是否为1，如果正确则连接建立成功，客户端和服务器端进入ESTABLISHED状态，完成三次握手，随后客户端与服务器端之间可以开始传输数据了

TCP断开连接四次挥手

第一次挥手 : 当主机1的数据都传输完成后,主机1向主机2发送连接释放报文,释放报文中FIN标志位FIN=1,seq=x.主机1发送FIN报文段后不能在继续发送数据,但是可以继续接收数据.主机1进入FIN_WAIT_1状态
第二次挥手 : 主机2接受到主机1发送的FIN报文后发送回复确认报文,确认报文包含ACK标志位ACK=1,确认号ack=x+1,序列号seq=y.此时主机2进入CLOSE_WAIT状态,主机1进入FIN_WAIT_2状态,主机2这个状态可能还要持续一段时间，因为还有数据没发完。
第三次挥手: 当数据发送完成后,主机2向主机1发送FIN报文段，请求关闭连接，同时主机2进入LAST_ACK状态
第四次分手：主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，然后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接；此时，主机1等待2MSL后依然没有收到回复，则证明Server端已正常关闭，那么，主机1也可以关闭连接了。

TCP 的 TIME_WAIT

首先调用close()发起主动关闭的一方，在接收到最后一个FIN报文后之后会进入time_wait的状态，也就说该发送方会保持2MSL时间之后才会回到初始状态。MSL值得是数据包在网络中的最大生存时间。产生这种结果使得这个TCP连接在2MSL连接等待期间，定义这个连接的四元组不能被使用。

为什么会有TIME_WAIT

为实现TCP全双工连接的可靠释放如果客户端等待的时间不够长，当服务端还没有收到 ACK 消息时，客户端就重新与服务端建立 TCP 连接就会造成以下问题 — 服务端因为没有收到 ACK 消息，所以仍然认为当前连接是合法的，客户端重新发送 SYN 消息请求握手时会收到服务端的 RST 消息，连接建立的过程就会被终止。
为使旧的数据包在网络因过期而消失为了保证新 TCP 连接的数据段不会与还在网络中传输的历史连接的数据段重复

为什么TCP连接的时候是3次？2次不可以吗

因为需要考虑连接时丢包的问题，如果只握手2次，第二次握手时如果服务端发给客户端的确认报文段丢失，此时服务端已经准备好了收发数(可以理解服务端已经连接成功)据，而客户端一直没收到服务端的确认报文，所以客户端就不知道服务端是否已经准备好了(可以理解为客户端未连接成功)，这种情况下客户端不会给服务端发数据，也会忽略服务端发过来的数据。如果是三次握手，即便发生丢包也不会有问题，比如如果第三次握手客户端发的确认ack报文丢失，服务端在一段时间内没有收到确认ack报文的话就会重新进行第二次握手，也就是服务端会重发SYN报文段，客户端收到重发的报文段后会再次给服务端发送确认ack报文。

为什么TCP连接的时候是3次，关闭的时候却是4次？

因为只有在客户端和服务端都没有数据要发送的时候才能断开TCP。而客户端发出FIN报文时只能保证客户端没有数据发了，服务端还有没有数据发客户端是不知道的。而服务端收到客户端的FIN报文后只能先回复客户端一个确认报文来告诉客户端我服务端已经收到你的FIN报文了，但我服务端还有一些数据没发完，等这些数据发完了服务端才能给客户端发FIN报文(所以不能一次性将确认报文和FIN报文发给客户端，就是这里多出来了一次)。

为什么客户端发出第四次挥手的确认报文后要等2MSL的时间才能释放TCP连接？

这里同样是要考虑丢包的问题，如果第四次挥手的报文丢失，服务端没收到确认ack报文就会重发第三次挥手的报文，这样报文一去一回最长时间就是2MSL，所以需要等这么长时间来确认服务端确实已经收到了。

一个网页从输入地址回车，到完整展示网页内容这段时间里，做了哪些工作

解析url获取协议,域名,资源路径
通过本地host,缓存,域名服务器解析域名对应的ip地址
浏览器发送tcp连接请求包
请求包经过传输层、网络层、数据链路层封装通过网卡到达路由器；
路由器转发数据包到所属运营商服务器；
运营商服务器通过寻址最短路径通过中继节点到达指定ip地址；
服务器端可能存在反向代理或者负载均衡，都是直接转发请求至上游服务器，当然也可以制定安全防御规则直接丢弃请求包；
上游服务器收到连接请求，返回回复报文同意连接；
浏览器校验ack，再次发送回复报文.TCP连接建立完成.然后根据请求传输数据包
四次挥手，连接关闭
渲染数据完成

客户端在使用HTTPS方式与Web服务器是怎么通信的

客户端请求服务器，服务器返回数字证书（里面包括，服务器公钥，网站地址，证书颁发机构）
解密证书，使用系统内置的CA公钥对数字签名进行解密得到的值是证书的散列值（hash）。客户端使用证书中声明的哈希算法（例如 SHA-256）对证书的主要内容再次计算散列值。将解密得到的散列值与它自己计算得到的散列值进行比较
解密证书，验证证书数字签名，通过操作系统和浏览器内置的CA证书信息。验证通过后，客户端生成一个随机密码，用接收到的服务器公钥将其加密，发送到服务器
用服务器私钥解密，得到随机密码
握手结束，之后的通信全部使用随机密码进行对称加密通信

TCP流量控制

如果发送者发送数据过快，接收者来不及接收，那么就会有分组丢失。量控制根本目的是防止分组丢失，它是构成TCP可靠性的一方面。
如何实现流量控制？
由滑动窗口协议（连续ARQ协议）实现。滑动窗口协议既保证了分组无差错、有序接收，也实现了流量控制。主要的方式就是接收方返回的 ACK 中会包含自己的接收窗口的大小，并且利用大小来控制发送方的数据发送。

拥塞控制

拥塞控制：拥塞控制是作用于网络的，它是防止过多的数据注入到网络中，避免出现网络负载过大的情况；
用的方法就是：（ 1 ）慢开始、拥塞避免（ 2 ）快重传、快恢复。

慢开始

TCP连接刚开始时，发送方的拥塞窗口（cwnd）大小设置得很小。每接收到一个确认ACK，cwnd会加倍。这样，窗口大小在每个RTT（往返时延）内都会翻倍，故名“慢开始”，但实际上它增长得很快。当cwnd达到一个叫做“拥塞阈值”（ssthresh）的值时，TCP会进入“拥塞避免”阶段。

拥塞避免

当cwnd达到拥塞阈值后，每经过一个RTT，cwnd仅增加1。这样，增长速率变为线性，而不是慢开始中的指数增长。
如果发生数据包丢失（通常通过三个重复ACK或超时来检测），则进入“快重传”和“快恢复”阶段。

快重传

如果发送方连续接收到三个重复的ACK，它会推断一个分组已经丢失（而不是等待超时再重新传输）。这种情况下，发送方会立即重新传输丢失的分组，不等待重传计时器超时。

快恢复

当进入快重传后，发送方会减小cwnd（通常设置为当前窗口的一半）。同时，它将进入“快恢复”模式。在这种模式下，每接收到一个重复的ACK，cwnd都会增加1。这样，发送方可以更快地恢复到一个合适的传输速率。当发送方接收到新的ACK时，它会退出“快恢复”模式，然后进入“拥塞避免”阶段。

HTTP 2.0

HTTP/1.0

增加了首部、状态码、权限、缓存、长连接（默认短连接）等规范,搭建了协议的基本框架

HTTP/1.1

长连接；强制客户端提供Host首部；

HTTP 2.0

HTTP/2使用多个二进制帧发送HTTP请求和响应，使用单个TCP连接，以流的方式多路复用。

http 2.0主要特点

二进制分帧层

HTTP2是二进制协议，他采用二进制格式传输数据可以在流上发送由多个帧组成的消息

多路复用

在一个tcp连接上建立多个流传输数据

头部压缩

HTTP2为此采用HPACK压缩格式来压缩首部

维护一份相同的静态字典

维护一份相同的动态字典

通过静态Huffman编码对传输的首部字段进行编码

服务器端推送

TCP UDP应用场景

TCP 提供的是一种面向连接、可靠的字节流服务。当数据的完整性和准确性比速度更重要时，TCP 是一个很好的选择.

TCP适用场景

网页浏览：HTTP 和 HTTPS 协议都是基于 TCP 的，因为在浏览网页时，我们需要保证接收到的所有数据都是完整和准确的。

邮件传输：SMTP，POP3 和 IMAP 邮件协议都是基于 TCP 的，因为在发送和接收邮件时，需要保证所有的数据都能被正确地传输。

文件传输：FTP 协议是基于 TCP 的，因为在传输文件时，需要保证文件的完整性。

UDP 提供的是一种无连接的服务，它发送数据时不需要建立连接，也不保证数据的顺序、完整性或可靠性。当速度和效率比可靠性更重要时，UDP 是一个很好的选择。

UDP适用场景：

实时应用：例如 VoIP（Voice over IP）和视频会议，这些应用需要快速传输数据，而且可以接受一些数据的丢失。

DNS 查询：DNS 查询通常使用 UDP，因为这些查询是小的、独立的，而且需要快速响应。

流媒体：音频和视频流通常使用 UDP，因为这些应用需要连续的数据流，而且可以接受一些数据的丢失。

HTTP/2 如何解决队头阻塞

一个 TCP 连接上可以并行发送多个 HTTP 请求。
每个请求被分成不同的“流”（stream），带有唯一标识。
数据帧可以交错传输，互不影响。
某个响应慢了，其他流上的请求不会被“阻塞”在应用层。

http2

HTTP/2 的本质是“单连接，多路复用”。

TCP 层面的队头阻塞

HTTP/2 所有流还是复用在同一个 TCP 连接上。如果 TCP 层面发生丢包，那么所有流的数据都只能等待这个丢失的包重传，所有流都会被卡住。这仍然是队头阻塞（这叫“TCP层队头阻塞”）。

http 和 https 区别

http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
https协议需要ca证书，费用较高。
使用不同的链接方式，端口也不同，一般而言，http协议的端口为80，https的端口为443

状态码

499

原因就是请求在指定的时间内没能拿到响应而关闭了连接。问题症结点为两处：1、指定的时间；2、程序处理的性能。

一般从php处理进程数、 fastcgi执行超时、 nginx等待时间 http转发配置错误等方面进行优化，防止服务器端处理http请求的时间过长。

502

502 Bad Gateway：作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。

1、nginx无法与php-fpm进行连接。

2、nginx在连接php-fpm一段时间后发现与php-fpm的连接被断开。检查检查php-fpm是否启动，如果没有启动php-fpm，将出现502错误检查php-fpm运行脚本是否超时，php-fpm终止了脚本的执行和执行脚本的Worker进程，nginx发现自己与php-fpm的连接断开。

504

Gateway Time-out 作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应。检查

nginx fastcgi_read_timeout 设置过小，返回504 当服务器压力过大，没有更多的php-fpm处理请求时，返回504

tcp如果只有一次握手会产生什么攻击

SYN Flood 攻击

YN Flood 是一种拒绝服务攻击（Denial of Service, DoS），攻击者向目标服务器发送大量的 SYN 请求，但不发送后续的 ACK。如果 TCP 只有一次握手，服务器会直接认为连接已建立成功，开始分配资源（如内存、CPU 等）来维持这个连接。
由于没有真正完成连接，服务器的资源会被大量消耗，导致服务器无法处理合法用户的请求。

ACK Storm 攻击

如果 TCP 只进行一次握手，客户端和服务器之间可能会产生不匹配的序列号。如果客户端没有发送 ACK 确认服务器的 SYN-ACK，服务器可能会继续重发 SYN-ACK 包，而客户端可能认为这些包是无效的并忽略它们。
这种不匹配可能会导致大量无用的包在网络中传输，形成网络拥塞

网络知识点