• 在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏。这种情况就叫做拥塞。

• ∑对资源的需求>可用资源

• TCP进行拥塞控制的算法有四种，即慢开始、拥塞避免、快重传和快恢复。

• 拥塞控制也叫基于窗口的拥塞控制。发送方维持一个叫做拥塞窗口cwnd的状态变量。发送方让自己的发送窗口等于拥塞窗口。

• 发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就可以再增大一些，以便把更多的分组发送事去，这样就可以提高网络的利用率。但只要网络出现拥塞或有可能出现拥塞，就必须把拥塞窗口减小一些，以减少注入到网络中的分组数，以便缓解网络出现的拥塞。

• 判断网络拥塞的依据就是出现了超时。

发送的最初执行慢开始，令 cwnd=1，发送方只能发送 1 个报文段；当收到确认后，将 cwnd 加倍，因此之后发送方能够发送的报文段数量为：2、4、8 …

为了防止拥塞窗口cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh状态变量。

慢开始门限ssthresh的用法下：

• 当cwnd<ssthresh时，使用上述的慢开始算法（cwnd 加倍）。
• 当cwnd>sthresh时，停止使用慢开始算法而改用拥塞避免算法（每个轮次只将 cwnd 加 1）。
• 当cwnd= ssthresh时，既可使用慢开始算法，也可使用拥塞避免算法。

拥塞避免算法的思路是让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发运方的拥塞窗口cwnd加1。因此在拥塞避免阶段就有”加法增大”的特点。这表明在拥塞避免阶段，拥塞窗口cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。

快重传算法规定，发送方只要一连收到3个重复确认，就知道接收方确实没有收到报文段M3，因而应当立即进行重传（即“快重传”），这样就不会出现超时，发送方也不就会误认为出现了网络拥塞。

因此执行快恢复，令 ssthresh = cwnd/2 ，cwnd = ssthresh，注意到此时直接进入拥塞避免。

PS：慢开始和快恢复的快慢指的是 cwnd 的设定值，而不是 cwnd 的增长速率。慢开始 cwnd 设定为 1，而快恢复 cwnd 设定为 ssthresh。

客户端和服务端都需要直到各自可收发，因此需要三次握手。

1、客户端发起请求（SYN）连接服务器端。

2、服务器端接受请求，然后发送确认和请求（SYN+ACK）给客户端。

3、客户端接受请求，向服务器端发送确认连接（ACK），客户端和服务器端连接成功，完成三次握手。

简化三次握手：

从图片可以得到三次握手可以简化为：C发起请求连接S确认，也发起连接C确认我们再看看每次握手的作用：

第一次握手：S只可以确认：自己可以接受C发送的报文段

第二次握手：C可以确认：S收到了自己发送的报文段，并且可以确认：自己可以接受S发送的报文段

第三次握手：S可以确认：C收到了自己发送的报文段

明明两次握手就可以建立起连接，为什么还需要第三次应答？

为了防止失效的连接请求报文段被服务端接收，从而产生错误。

• 因为当服务器端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。

• 其中ACK报文是用来应答的，SYN报文是用来同步的。

• 但是关闭连接时，当服务器端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。

• 只有等到我服务器端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。

• 故需要四步握手。

当失败时服务器并不会重传ack报文，而是直接发送RTS报文段，进入CLOSED状态。

这样做的目的是为了防止SYN洪泛攻击。

• TCP设有一个保活计时器
• 服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时
• 若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次
• 若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

根本区别：进程就是操作系统资源分配的基本单位，而线程是任务调度和执行的基本单位。

• 一个程序至少有一个进程,一个进程至少有一个线程.

• 线程的划分尺度小于进程，使得多线程程序的并发性高。

• 进程在执行过程中拥有独立的内存单元，而多个线程共享内存，从而极大地提高了程序的运行效率。

• 线程在执行过程中与进程还是有区别的。每个独立的进程有一个程序运行的入口、顺序执行序列和程序的出口。但是线程不能够独立执行，必须依存在应用程序中，由应用程序提供多个线程执行控制。

• 从逻辑角度来看，多线程的意义在于一个应用程序中，有多个执行部分可以同时执行。但操作系统并没有将多个线程看做多个独立的应用，来实现进程的调度和管理以及资源分配。这就是进程和线程的重要区别。

副作用指对服务器上的资源做改变，搜索是无副作用的，注册是副作用的。

幂等指发送M和N次请求（两者不相同且都大于1），服务器上的资源的状态一致，比如注册10个和11个账号是不幂等的，对文章进行更改10次和11次是幂等的。

在规范的应用场景上说，Get多用于无副作用，幂等的场景，例如搜索关键字。Post多用于副作用，不幂等的场景，例如注册。

• get参数通过url传递，post放在request body中。

• get请求在url中传递的参数是有长度限制的，而post没有。

• get比post更不安全，因为参数直接暴露在url中，所以不能用来传递敏感信息。

• get请求只能进行url编码，而post支持多种编码方式。

• get请求会被浏览器主动cache，而post不会，除非手动设置。

• get请求参数会被完整保留在浏览历史记录里，而post中的参数不会被保留。

• get产生一个TCP数据包；post产生两个TCP数据包。

• get在浏览器回退时是无害的，而post会再次提交请求。

• 对参数的数据类型，get只接受ASCII字符，而post没有限制。

• get和post本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。

• Cookie和session都可用来存储用户信息

• cookie存放于客户端，session存放于服务器端

• 因为cookie存放于客户端有可能被窃取，所以cookie一般用来存放不敏感的信息，比如用户设置的网站主题，敏感的信息用session存储，比如用户的登陆信息，session可以存放于文件，数据库，内存中都可以

• cookie可以服务器端响应的时候设置，也可以客户端通过JS设置

• cookie会在请求时在http首部发送给客户端

• cookie一般在客户端有大小限制，一般为4K

共同点：都是保存在浏览器端，并且是同源的

localStorage作为H5的新添特征，与cookie的区别在于：

只存储在客户端本地，而不会随http请求发送到服务器端

并且只能通过手动删除缓存来清除，不能设置失效时间

如果不给cookie设置过期时间，他会在关闭浏览器的时候销毁

sessionStorage和localStorage两者虽然对存储的内容比cookie（4k左右）大得多（5M左右），但是存入的东西都被转换成了字符串，也就是说无法存入数组或者对象，就算存入了也会被转化为字符串。

1.设置cookie一天后过期

function setCookie(name,expireday){
    var dayobject = new Date();  // Date()函数获取当前的日期和时间
    // getTime()函数获取的事1970年1月1号至今的毫秒数
    // 注意要多加8小时，我们位于东八区比标准时间相差8小时
    var daynum = dayobject.getTime() + expireday*(24+8)*60*60*1000;
    // 计算过期时间毫秒数
    dayobject.setTime(daynum);
    // 设置超时的时间
    alert('name=' + name + ';' + 'expires=' + dayobject.toUTCString());
    document.cookie = 'name=' + name + ';' + 'expires=' + dayobject.toUTCString();
}
setCookie('coco',1)

2.设置cookie马上过期

function delCookie(name){
    var expires = new Date();
    expires.setTime(expires.getTime() - 1);
    document.cookie = 'name='+name+';'+'expires=' + expires.toGMTString();
}
// 设置cookie的过期时间是比当前时间提前一秒，也就是立马过期了。

localStorage.setItem(key, value);

localStorage,getItem(key);

sessionStorage.setItem(key, value);

sessionStorage.setItem(key, value);

补充说明一下cookie的作用：

**保存用户登录状态。**例如将用户id存储于一个cookie内，这样当用户下次访问该页面时就不需要重新登录了，现在很多论坛和社区都提供这样的功能。 cookie还可以设置过期时间，当超过时间期限后，cookie就会自动消失。因此，系统往往可以提示用户保持登录状态的时间：常见选项有一个月、三个月、一年等。

**跟踪用户行为。**例如一个天气预报网站，能够根据用户选择的地区显示当地的天气情况。如果每次都需要选择所在地是烦琐的，当利用了cookie后就会显得很人性化了，系统能够记住上一次访问的地区，当下次再打开该页面时，它就会自动显示上次用户所在地区的天气情况。因为一切都是在后 台完成，所以这样的页面就像为某个用户所定制的一样，使用起来非常方便定制页面。如果网站提供了换肤或更换布局的功能，那么可以使用cookie来记录用户的选项，例如：背景色、分辨率等。当用户下次访问时，仍然可以保存上一次访问的界面风格。

缓存分为两种：强缓存和协商缓存，根据响应的header内容来决定。

强缓存：在请求资源的时候，会从header里面读取是否是强缓存，在有效的时间内，从缓存里读取，不能从服务那里读取。实现强缓存可以通过两种响应头实现：Expires和Cache-Control。强缓存表示在缓存期间不需要请求，state code为200。

协商缓存：通过服务器来判断缓存是否可用。如果缓存过期了，我们就可以使用协商缓存来解决问题。协商缓存需要请求，如果缓存有效会返回304。

(1)http和https的基本概念

100 Continue 继续，一般在发送post请求时，已发送了http header之后服务端将返回此信息，表示确认，之后发送具体参数信息

200 OK 请求成功，正常返回信息

201 Created 请求成功并且服务器创建了新的资源

202 Accepted 服务器已接受请求，但尚未处理

204 No Content 请求处理成功，但没有资源可返回

206 Partial Content 对资源某一部分的请求

301 Moved Permanently 永久重定向，请求的网页已永久移动到新位置。

302 Found 临时性重定向，表示资源临时被分配到了新的URL。

303 See Other 临时性重定向，且总是使用 GET 请求新的 URL。

304 Not Modified 自从上次请求后，请求的网页未修改过。如果客户端发送了一个带条件的GET 请求且该请求已被允许，而文档的内容（自上次访问以来或者根据请求的条件）并没有改变，则服务器应当返回这个304状态码。

307 Temporary Redirect 临时重定向，会遵照浏览器标准，不会从POST变成GET。

400 Bad Request 请求无效，请求报文存在语法错误。服务器无法理解请求的格式，客户端不应当尝试再次使用相同的内容发起请求。 请求无效

产生原因：

前端提交数据的字段名称和字段类型与后台的实体没有保持一致

前端提交到后台的数据应该是json字符串类型，但是前端没有将对象JSON.stringify转化成字符串。

解决方法：

对照字段的名称，保持一致性

将obj对象通过JSON.stringify实现序列化

401 Unauthorized 身份认证失败 当前请求需要用户验证 请求未授权。

403 Forbidden 服务器已经得到请求，但是拒绝执行

404 Not Found 资源请求失败

500 Internal Server Error 服务器发生不可预知的错误

503 Service Unavailable 服务器宕机或过载

总结一下

1xx 临时响应，需要请求者继续执行操作

2xx 成功处理请求

3xx 重定向

4xx 客户端请求错误

5xx 服务器端错误

GET, POST, HEAD, OPTIONS, PUT, DELETE, TRACE, CONNECT

可以将http首部分为通用首部，请求首部，响应首部，实体首部

通用首部表示一些通用信息，比如date表示报文创建时间，

请求首部就是请求报文中独有的，如cookie，和缓存相关的如if-Modified-Since

响应首部就是响应报文中独有的，如set-cookie，和重定向相关的location，

实体首部用来描述实体部分，如allow用来描述可执行的请求方法，content-type描述主题类型，content-Encoding描述主体的编码方式

Request Header:

1. GET /sample.Jsp HTTP/1.1 //请求行
2. Host: www.uuid.online/ //请求的目标域名和端口号
3. Origin: http://localhost:8081/ //请求的来源域名和端口号 （跨域请求时，浏览器会自动带上这个头信息）
4. Referer: https:/localhost:8081/link?query=xxxxx //请求资源的完整URI
5. User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36 //浏览器信息
6. Cookie: BAIDUID=FA89F036:FG=1; BD_HOME=1; sugstore=0 //当前域名下的Cookie
7. Accept: text/html,image/apng //代表客户端希望接受的数据类型是html或者是png图片类型
8. Accept-Encoding: gzip, deflate //代表客户端能支持gzip和deflate格式的压缩
9. Accept-Language: zh-CN,zh;q=0.9 //代表客户端可以支持语言zh-CN或者zh(值得一提的是q(0~1)是优先级权重的意思，不写默认为1，这里zh-CN是1，zh是0.9)
10. Connection: keep-alive //告诉服务器，客户端需要的tcp连接是一个长连接

Response Header:

XSS（跨站脚本攻击）是指攻击者在返回的HTML中嵌入javascript脚本，为了减轻这些攻击，需要

CSRF：跨站请求伪造，在受害者访问一个网站时，其 Cookie 还没有过期的情况下，攻击者伪造一个链接地址发送受害者并欺骗让其点击，从而形成 CSRF 攻击。可以理解为攻击者盗用了用户的身份，以用户的名义发送了恶意请求，比如用户登录了一个网站后，立刻在另一个ｔａｂ页面访问量攻击者用来制造攻击的网站，这个网站要求访问刚刚登陆的网站，并发送了一个恶意请求，这时候CSRF就产生了，比如这个制造攻击的网站使用一张图片，但是这种图片的链接却是可以修改数据库的，这时候攻击者就可以以用户的名义操作这个数据库

预防：

• 验证 HTTP Referer 字段
• 在请求地址中添加 token 并验证
• 在 HTTP 头中自定义属性并验证。

XSS：跨站脚本攻击， 是发生在目标用户的浏览器层面上的，当渲染DOM树的过程成发生了不在预期内执行的JS代码时，就发生了XSS攻击。大多数XSS攻击的主要方式是嵌入一段远程或者第三方域上的JS代码。实际上是在目标网站的作用域下执行了这段js代码。攻击者通过注入恶意的脚本，在用户浏览网页的时候进行攻击，比如获取cookie，或者其他用户身份信息，可以分为存储型和反射型，存储型是攻击者输入一些数据并且存储到了数据库中，其他浏览者看到的时候进行攻击，反射型的话不存储在数据库中，往往表现为将攻击代码放在url地址的请求参数中

预防：

• 在HTTP头部配上，Set-Cookie=<cookie-value>

  • httponly-这个属性可以防止XSS,它会禁止javascript脚本来访问cookie。
  • secure - 这个属性告诉浏览器仅在请求为https的时候发送cookie。

• 转义输入输出的内容，对于引号，尖括号，斜杠进行转义

• CSP

  • CSP（内容安全策略）是一个额外的安全层，用于检测并削弱某些特定类型的攻击，包括跨站脚本（XSS）和数据注入攻击等。

  • CSP本质上是建立白名单，规定了浏览器只能够执行特定来源的代码。

  • 通常可以通过HTTP Header中的Content-Security-Policy来开启CSP

    只允许加载本站资源 Content-Security-Policy: default-src 'self'

    只允许加载HTTPS协议图片 Content-Security-Policy: img-src https://*

    允许加载任何来源框架 Content-Security-Policy: child-src 'none'

URL(Uniform Resource Locator) 地址用于描述一个网络上的资源, 基本格式如下

schema://host[:port#]/path/.../[?query-string][#anchor]

schema 指定低层使用的协议(例如：http, https, ftp)

host HTTP服务器的IP地址或者域名

port# HTTP服务器的默认端口是80，这种情况下端口号可以省略。

​ 如果使用了别的端口，必须指明，例如 http://www.cnblogs.com:8080/

path 访问资源的路径

query-string 发送给http服务器的数据

anchor- 锚

URL 的一个例子

http://www.mywebsite.com/sj/test/test.aspx?name=sviergn&x=true#stuff

Schema:                 http
host:                   www.mywebsite.com
path:                   /sj/test/test.aspx
Query String:           name=sviergn&x=true
Anchor:                 stuff

1、客户机发出查询请求，在本地计算机缓存查找，若没有找到，就会将请求发送给dns服务器

2、先发送给本地dns服务器，本地的就会在自己的区域里面查找，若找到，根据此记录进行解析，若没有找到，就会在本地的缓存里面查找

3、本地服务器没有找到客户机查询的信息，就会将此请求发送到根域名dns服务器

4、根域名服务器解析客户机请求的根域部分，它把包含的下一级的dns服务器的地址返回到客户机的dns服务器地址

5、客户机的dns服务器根据返回的信息接着访问下一级的dns服务器

6、这样递归的方法一级一级接近查询的目标，最后在有目标域名的服务器上面得到相应的IP信息

7、客户机的本地的dns服务器会将查询结果返回给我们的客户机

8、客户机根据得到的ip信息访问目标主机，完成解析过程

1.在浏览器中输入url

首先需要找到这个url域名的服务器ip,为了寻找这个ip，浏览器首先会寻找缓存，查看缓存中是否有记录，缓存的查找记录为：浏览器缓存-》系统缓存-》路由器缓存，缓存中没有则查找系统的hosts文件中是否有记录，如果没有则查询DNS服务器

2.应用层DNS解析域名

得到服务器的ip地址后，浏览器根据这个ip以及相应的端口号，构造一个http请求，这个请求报文会包括这次请求的信息，主要是请求方法，请求说明和请求附带的数据，并将这个http请求封装在一个tcp包中，这个tcp包会依次经过传输层，网络层，数据链路层，物理层到达服务器，服务器解析这个请求来作出响应，返回相应的html给浏览器

3.应用层客户端发送HTTP请求

4.传输层TCP传输报文

5.网络层IP协议查询MAC地址

6.数据到达数据链路层

7.服务器接收数据

8.服务器处理请求并返回HTTP报文

9.浏览器生成DOM树，解析css和js，渲染页面，直至显示完成

10.连接结束

Token是在客户端频繁向服务端请求数据，服务端频繁的去数据库查询用户名和密码并进行对比，判断用户名和密码正确与否，并作出相应提示，在这样的背景下，Token便应运而生。Token是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个Token便将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。

当HTTP协议中Content-Type为 application/json 的时候，HTTP POST请求数据必须是JSON的。

当Content-Type为 x-www-form-urlencoded 的时候，POST 的请求数据必须是表单的。

因为浏览器会有并发请求限制，在HTTP/1.1时代，每个请求都需要建立和断开，消耗了好几个RTT时间，并且由于TCP慢启动的原因，加载体积大的文件会需要更多的时间。

在HTTP/2.0中引入了多路复用，能够让多个请求使用同一个TCP链接，极大地加快了网页的加载速度。并且还支持Header压缩，进一步的减少了请求的数据大小。