浏览器

cookie，sessionStorage和localStorage

• 相同点：cookie，sessionStorage和localStorage都是存储在浏览器端的。
• 不同点：cookie数据始终在浏览器请求中被携带，在浏览器端和服务器端来回传递的；sessStorage和localStorage同属于webStorage，仅在本地保存，不会传递到服务器端
• 存活时间：cookie在设置的存活时间之前一直有效，sessionStorage在浏览器窗口关闭之前一直有效，localStorage始终有效
• 存储大小：cookie只有4KB，sessStorage和localStorage存储空间大一些
• 作用域：sessionStorage不在不同的浏览器窗口中共享，即使同一个页面，而cookie和localStorage在同源窗口（协议、域名、端口相同）中均共享

cookie和session

cookie数据存储在客户端，session数据存储在服务器。相比session，cookie不是很安全，别人可以分析存储在本地的cookie并进行cookie诈骗；而session，当访问增多时，会比较占用服务器性能。

总结：

• Cookie受到浏览器同源策略的限制，A页面的Cookie无法被B页面的Cookie访问和操作。

• Cookie最大存储容量一般为4KB，由服务器生成，在HTTP报文首部设置 Set-Cookie可以指定生成Cookie的内容和生命周期，如果由浏览器生成则在关掉浏览器后失效。

• Cookie存储在浏览器端，由于每次发送HTTP请求默认会把Cookie附到HTTP首部上去，所以Cookie主要用来身份认证，而不用来存储其他信息，防止HTTP报文过大。

• Session存储在服务器，主要与Cookie配合使用完成身份认证和状态保持的功能。只有Cookie或只有Session都无法完成身份认证和状态保持的功能。

对Cookie和Session实现的身份认证和状态保持功能做一个举例。

假设现在有一个学生信息管理系统，此时数据库已经有学生的相关信息（账号、密码、个人信息等等）。

然后当学生登录这个系统，通过POST请求把用户的账户密码发送到后台服务器。当后台服务器接收到这些参数的时候，会跟数据库保存的记录进行匹配。

一旦匹配成功，也就是用户的账号密码都正确的情况下，这个时候后台服务器会生成Session（一个为客户端开辟存储空间，用来保存会话的状态信息），并生成一个相应的SessionID，可以是用户名或者其他能够唯一标识用户的字段。然后后台服务器会返回响应告知客户端登录成功，可以进行后续的操作。此时，后台服务器会在HTTP响应报文中添加一个字段 Set-Cookie，它的值是当前Session的SessionID，（这个SessionID是指向我们当前的那个Session的，在Node的Express中express-session会封装好这个过程）当然还会设置Cookie的其他属性，比如说过期时间 Expires等等。

当浏览器接收到这个HTTP响应报文的时候，就会在本地设置一个Cookie，它的过期时间由响应报文中 Set-Cookie中的 Expires字段的值决定，如果为空，则关闭浏览器（即会话结束时）后失效。

之后，每次向后台服务器发送请求的时候，浏览器默认会把这个Cookie加在HTTP请求报文的Cookie中。这样，每次后台服务器接收到请求的时候，会根据Cookie中的SessionID去找到我们的Session。

假如这个SessionID映射得到Session，那么这个时候说明浏览器是已经登录过了。于是，就可以进行后续的一些相关的操作。

另外，值得一提的是，Session机制决定了当前客户只会获取到自己的Session，而不会获取到别人的Session。各客户的Session也彼此独立，互不可见。也就是说，当多个客户端执行程序时，服务器会保存多个客户端的Session。获取Session的时候也不需要声明获取谁的Session。

这就是Cookie和Session做状态保持和身份验证的一个具体的例子

Doctype

Doctype申明位于文档的开头，用于告诉浏览器以什么样的方式来渲染页面，有混杂模式和严格模式两种

混杂模式向后兼容，模拟老浏览器，防止浏览器版本过旧不兼容页面

严格模式是将JS和排版以浏览器最高的标准运行

强缓存和协商缓存（待补充）

服务器上的数据是会有更新的，我们不能一直使用浏览器的本地缓存，这样就只能一直使用旧数据。我们希望当服务器的数据发生更新时，浏览器会请求更新数据，如果服务器上的数据没有更新我们就使用本地数据，这样能节省因网络请求而产生的资源浪费。

浏览器渲染的基本步骤

1. 根据服务器发送的HTML生成dom树，解析CSS文件生成CSSOM树
2. 结合DOM树和CSSOM树生成render树，也就是渲染树
3. 在render树中对每个节点进行布局，计算每个元素的大小，确定其在屏幕中的位置
4. 绘制。根据render树和布局将显示页面

HTTP

HTTP协议

HTTP协议及超文本传输协议，是简历在TCP/IP协议之上的一种应用，用于客户端和服务器端之间通信的协议。HTTP协议最显著的特点就是客户端每次发送的请求都需要服务器端的回应，在请求结束之后会释放连接，从建立连接到释放连接成为“一次连接”。

1）在HTTP 1.0中，客户端的每次请求都要求建立一次单独的连接，在处理完本次请求后，就自动释放连接。

2）在HTTP 1.1中则可以在一次连接中处理多个请求，并且多个请求可以重叠进行，不需要等待一个请求结束后再发送下一个请求。
由于HTTP在每次请求结束后都会主动释放连接，因此HTTP连接是一种“短连接”，要保持客户端程序的在线状态，需要不断地向服务器发起连接请求。通常的做法是即使不需要获得任何数据，客户端也保持每隔一段固定的时间向服务器发送一次“保持连接”的请求，服务器在收到该请求后对客户端进行回复，表明知道客户端“在线”。若服务器长时间无法收到客户端的请求，则认为客户端“下线”，若客户端长时间无法收到服务器的回复，则认为网络已经断开。

HTTP和HTTPS

基本概念和区别

HTTP是用于web浏览器和Web服务器之间通信的协议，超文本传输协议，传输的信息是未加密的明文。而HTTPS是具有安全性的SSL加密传输的协议，可进行身份认证和加密传输。HTTP的端口是80，HTTPS的端口是443.

Get和Post请求的区别

Get是通过url请求，而post请求则是在request body中

get请求只能通过url编码，而post有多重编码方式

get请求参数直接暴露在url中，不如post安全

get请求在url中有长度限制，post没有

get请求参数会被完整保存在浏览器的历史记录中，而post不会

Get产生一个TCP数据包，而Post产生两个TCP数据包

HTTP状态码

1***，服务器已收到请求，需要请求者继续执行操作

2***，服务器已经接收并处理了请求

3***，重定向，需要进一步操作以完成请求

4***，浏览器发生错误

5***，服务器发生错误

200，请求成功，所请求的数据也会随着该码返回

202，服务器已接收请求，但是未处理

400，请求有误，服务器无法理解

401，当前请求需要验证用户

403，服务器接收到请求，但是拒绝执行

404，请求的页面没有找到

502，网关出错

TCP协议

三次握手

TCP/IP协议是因特网的通信协议。简历TCP连接需要经过三次握手

第一次握手：客户端发送syn包（SEQ=x，SYN=1）到服务器，并进入SYN_SEND状态，等待服务器确认

第二次握手：第 2 次握手实际上是分两部分来完成的，即 SYN+ACK（请求和确认）报文。

• 服务器收到了客户端的请求，向客户端回复一个确认信息（ACK=x+1）。

• 服务器再向客户端发送一个 SYN 包（SEQ=y）建立连接的请求，此时服务器进入 SYN_RECV 状态。

第三次握手：是客户端收到服务器的回复（SYN+ACK 报文）。此时，客户端也要向服务器发送确认包（ACK）。此包发送完毕客户端和服务器进入 ESTABLISHED 状态，完成 3 次握手

三次握手成功之后，客户端和服务器端的才开始正式传送数据。理想状态下，直到客户端和服务器端任何一方断开连接之前，TCP连接一直保持。客户端和服务器端都可以主动发起断开连接的请求，断开需要经历四次握手。

四次挥手

与建立连接的“三次握手”类似，断开一个TCP连接则需要“四次握手”。

第一次挥手：主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但是，此时主动关闭方还可以接受数据。

第二次挥手：被动关闭方收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。

第三次挥手：被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。

第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。

HTTPS握手

1. 客户端发起HTTPS请求

2. 服务端的配置

采用HTTPS协议的服务器必须要有一套数字证书，可以是自己制作或者CA证书。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用CA证书则不会弹出提示页面。这套证书其实就是一对公钥和私钥。公钥给别人加密使用，私钥给自己解密使用。

3. 传送证书

这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等。

4. 客户端解析证书

这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值，然后用证书对该随机值进行加密。

5. 传送加密信息

这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

6. 服务段解密信息

服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。

7. 传输加密后的信息

这部分信息是服务段用私钥加密后的信息，可以在客户端被还原。

8. 客户端解密信息

客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容。

TCP流量控制

流量控制就是让发送方的发生速率不要太快，要让接收方来的及接收，不然数据会溢出丢失。

流量控制是利用滑动窗口机制实现的。接收端反馈自己的接收窗口的剩余大小，发送端根据接收到的反馈信息调整下一步发送多少。

 TCP的窗体单位是字节。不是报文段。TCP连接建立时的窗体协商过程在图中没有显示出来。再设每个报文段为100字节长，而数据报文段序号的初始值设为1。大写ACK表示首部中的确认位ACK（等于1才有效），小写ack表示确认字段的值。 

图中B进行了三次流量控制。第一次把窗体降低到 rwnd = 300 。第二次又减到了 rwnd = 100 ，最后减到 rwnd = 0 。即不同意发送方再发送数据了。这样的使发送方暂停发送的状态将持续到主机B又一次发出一个新的窗体值为止。

死锁：假设B在向A发送了零窗体报文段后不久，B的接收缓存又有了一些存储空间，于是B向A发送了一个rwnd=400的报文段，然而这个报文段在传送过程中丢失了，A就一直等待B发送非零窗体的报文通知，而B一直等待A发送数据，假设没有不论什么措施的话。这话死锁的局面会一直延续下去。

为了解决问题，TCP为每个连接设有一个持续计时器。仅仅要TCP连接的一方收到对方的零窗体通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗体探测报文段（携1字节的数据），对方在收到探测报文段后。在对该报文段的确认时给出如今的窗体值，假设窗体值仍未零，则收到这个报文段的一方就又一次设置持续计时器，假设窗体不为零。那么死锁的僵局就被打破了。

糊涂窗口综合证： TCP接收方的缓存已满，接收方一次只从接收缓存中确认1字节，然后向发送方发送确认并把窗口设置为1个字节（但发送的数据报为40字节的的话）。接收，发送方又发来1个字节的数据（发送方的IP数据报是41字节）。接收方发回确认，仍然将窗口设置为1个字节。这样，网络的效率很低。要解决这个问题，可让接收方等待一段时间，使得或者接收缓存已有足够空间容纳一个最长的报文段，或者等到接收方缓存已有一半空闲的空间。只要出现这两种情况，接收方就发回确认报文，并向发送方通知当前的窗口大小。此外，发送方也不要发送太小的报文段，而是把数据报积累成足够大的报文段，或达到接收方缓存的空间的一半大小。

拥塞控制

拥塞控制是全局的问题，是由网络中所有主机，路由器共同完成的，而流量控制只涉及到端端之间的传输，是局部问题。

拥塞控制是防止网络中注入太多数据，导致网络中的路由器或者链路过载，

拥塞窗口：拥塞窗口的大小取决于网络的拥塞程度，拥塞窗口是动态变化的。发送让自己的发送窗口=min（拥塞窗口，接收方的接收窗口）。发送窗口不是一直等于拥塞窗口，在网络情况好的情况下，拥塞窗口会不断增加，发送方的窗口自然也会随着增加，但是接收方的能力有限，在发送方的窗口达到某个大小时就不在发生变化了。

如何确认网络拥塞？1.发送方发送一些报文时，如果发送没有在规定的时间间隔内收到接收方的应答（超时），则就可以认为网络拥塞；2.收到三个重复的ACK（快速重传机制）， 简单来说，就是某一个包丢了，但是它之后的包都正常达到，那么接受方发现只有某一个包丢了，就向源端连续发送三个ACK，ACK带有期待的包的序号，发送端收到这三个连续ACK，便不等到段计时器超时，直接发送对应的序号的数据包，这就是快速重传机制。这两个方法，能让发送方掌握网络发生了拥塞，进而采用算法来调整自己的发送速率。

速率调整算法的基本思想是：当发生丢包事件时，降低发送速率（减少拥塞窗口CongWin的大小）

慢启动和逐步递增

（1）最初让拥塞窗口按照指数级增长，这样可以提高发送数据吞吐量；

（2）当拥塞窗口大小到达慢启动门限后，改成线性增长，目的是减少拥塞窗口的增长速度；

（3）当发送端检测的网络拥塞时，立即把拥塞窗口减小为1，把慢启动门限调整为出现拥塞时拥塞窗口的一半目的是可以减少向网络中注入的数据量。

（4）重新开始指数级增长和线性增长。

注：图中窗口的单位都是报文段
（1）当 TCP 连接进行初始化时：
        发送窗口：swnd = 1 
        慢开始阈值：ssthresh = 16
（2）发送端收到 ACK1 （确认 M0，期望收到 M1）后，将 cwnd 从 1 增大到 2，于是发送端可以接着发送 M1 和 M2 两个报文段（指数增长）
（3）接收端发回 ACK2 和 ACK3。发送端每收到一个对新报文段的确认 ACK，就把发送端的拥塞窗口加 1。现在发送端的 cwnd 从 2 增大到 4，并可发送 M4 ~ M6共 4个报文段。（指数增长）
（4）当swnd >= ssthresh，swnd执行拥塞避免算法，swnd窗口按线性规律增长。（加法增大）
（5）当发送 超时，此时swnd = 24 ：
        ssthresh = swnd/2 = 12；（乘法减小）
        swnd = 1
（6）重复地2步

快重传和快恢复

快重传

发送端只要一连收到三个重复的 ACK 即可断定有分组丢失了，就应立即重传丢失的报文段而不必继续等待重传计时器的超时

快恢复

拥塞窗口减半，按线性增长

TCP和UDP的区别？

TCP提供面向连接的、可靠的数据流传输，而UDP提供的是非面向连接的、不可靠的数据流传输。

TCP传输单位称为TCP报文段，UDP传输单位称为用户数据报文段。

TCP注重数据安全性，UDP数据传输快，因为不需要连接等待，少了许多操作，但是其安全性却一般。

TCP对应的协议：

（1） FTP：定义了文件传输协议，使用21端口。

（2） Telnet：一种用于远程登陆的端口，使用23端口，用户可以以自己的身份远程连接到计算机上，可提供基于DOS模式下的通信服务。

（3） SMTP：邮件传送协议，用于发送邮件。服务器开放的是25号端口。

（4） POP3：它是和SMTP对应，POP3用于接收邮件。POP3协议所用的是110端口。

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

UDP对应的协议：

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

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

（3） TFTP(Trival File Tran敏感词er Protocal)，简单文件传输协议，该协议在熟知端口69上使用UDP服务。

面向连接和非面向连接的服务的特点是什么？

面向连接的服务，通信双方在进行通信之前，要先在双方建立起一个完整的可以彼此沟通的通道，在通信过程中，整个连接的情况一直可以被实时地监控和管理。

非面向连接的服务，不需要预先建立一个联络两个通信节点的连接，需要通信的时候，发送节点就可以往网络上发送信息，让信息自主地在网络上去传，一般在传输的过程中不再加以监控。