目录
1.HTML资源交互
（1）媒体加载
（2）静态页面跳转
（3）动态页面
（4）GET和POST传参的区别
2.网页管理
（1）网页的权限管理
（2）临时重定向和永久重定向
①永久重定向（301）
②临时重定向（302）
①会话保持
③session
3.搜索引擎
（1）搜索引擎和浏览器的关系
（2）搜索引擎的构建和更新
1.HTML资源交互
在这里，我重点讲解前后端之间的联系，它们是如何联系起来的，不会过多涉及前端语法。
（1）媒体加载
如果有图片、音频等需要出现在网页中，这些资源又都来自不同的文件，那么当客户端访问这些html时，这些媒体应该怎么加载呢？
对于绝大多数情况，就是第一次直接返回带有媒体链接的html网页（只有媒体文件的路径），客户端接收到回应后再根据里面的链接多次发送URL请求，之后服务器再多次以二进制方式读取媒体文件并返回（每次返回时响应报头都会声明媒体类型）。所以我们会发现有时网慢的时候，一般都是先刷新出文字大纲之类的，后面慢慢地才会出现图片。在只显示文字期间，客户端正源源不断地根据第一次收到的html文件里面的链接访问媒体资源。当然，对于特别小的图标，会被直接读到html里面并用Base64编码，在第一次响应中就让客户端看到。
如果不进行优化的话，当遇到一个html里面大量图片时，由于一个短链接就获取一个资源，且短链接会导致频繁访问资源，造成浪费。因此现在的HTTP版本允许在同一次TCP连接中请求媒体资源。其具体实现来源于HTTP报头的Connection字段，主要用于控制客户端和服务器之间的连接状态。Connection: keep-alive表示支持长链接，在一个TCP连接内，客户端会自动扫描文本，并多次访问服务端的资源，直到数据被请求完。这种复用TCP的技术大大减少了服务器的压力。
（2）静态页面跳转
.html里面遇到<a>标签的时候，就说明有一个页面跳转链接，如<a href="/about.html">关于我们</a> ，点击“关于我们”就会静态跳转到相应的页面，即web_root/about.html
当然，实际情况可能不止这一个，如果是<a href="/about">关于我们</a>，这意味着什么呢？
这需要由服务器自行处理：当about是一个目录时，有可能访问的就会是/about/index.html；如果about本身就是一个无扩展名的文件，有可能就直接访问它；也可能服务器会通过配置自动补齐扩展名；还有一种是申请访问动态页面，后面会讲。
<!-- 跳转到一个动态路由（如/about） -->
<a href="/about">关于我们</a><!-- 跳转到一个带后缀的动态页面（如.php） -->
<a href="/user.php?id=123">用户信息</a>这个跳转其实就是在用户点击链接后，由用户的浏览器自动形成新的URL（新的访问请求）向目标服务发起请求，然后等待服务端的回应。
以上大多是属于静态页面的跳转，即点击链接后会直接到达新的网页。
除了直接跳转，还有一种借助JavaScript直接刷新页面，更新页面内容，这种情况下就不会跳转到新的静态网页，看起来还是在原来的网站，但内容更新了。
（3）动态页面
除了静态网页，但还有一种很相似的URL，如输入账号密码后点击登录会出现/login?username=SGlow&passwd=123456，这是要跳转吗？静态网页能传参吗？后面的参数是什么意思呢？这就涉及到动态网页的知识了。
用户在网页中输入信息，需要form表单创建搜索框（其中input标签可以设置type为文本），button提供按钮提交信息，action表示提交给谁，点击后action自动拼接到网址后，发起访问。
<form action="/search" method="GET"><!-- 搜索输入框：type="text"，name="query" 定义参数名 --><input type="text" name="query" placeholder="输入搜索关键词" required><!-- 提交按钮：触发表单默认提交 --><button type="submit">搜索</button>
</form>这里点击提交之后，就会带着参数访问如www.test.com/search?query=xxx（input里面的name规定了该参数的名字）。但是，/search并不是一个静态网页，而是动态的。动态网页的一个很强的特征就是它能够接收参数。可以说，/search本身并不是一个实体，在Web根目录下找不到这个文件或者目录，它只是一个访问接口，当服务端接收到这个接口访问请求时，就会单独拉出来处理。
服务器收到动态页面请求后能够读取接收到的参数，并且给出响应。当请求端收到回应后就会显示收到的结果，并将当前页面的URL修改为请求发出的URL。
这里我们就可以看到，我们并不是真的打开了服务端的某个文件，而是我们访问动态网页，服务器通过参数返回了结果给我们，再由我们浏览器渲染出结果后显示出来，并且更新URL为当时请求动态网页时的URL而已。
在这里总结一下，静态网页的跳转最有代表的就是<a>标签，大多数情况下会跳转到一个有实体的网页中，即在服务端的Web根目录中一定存在这么一个文件。而动态页面就一定没有实体，客户端的/test实际上会被对方的服务器单独处理，读取请求的参数，返回结果给客户端。在客户端眼里就像是访问了一个文件一样，所以按照结果渲染页面，并更改URL为请求的URL。
至于是静态网页还是动态网页，区分最粗暴的方法是看有没有参数传递，有没有文件后缀。但有的静态网页也能处理参数（前端），没有后缀时也可能是静态网页，如前面提过的<a href="/about">关于我们</a>。最根本的判断标准就是动态网页没有实体，而静态网页有实体。
（4）GET和POST传参的区别
我们已经讲过动态页面可以接收参数，参数的传递方式随请求方法有所不同。POST传参是通过正文传参，GET传参则直接体现在URL中。一般情况下不推荐用GET提交私密数据的参数，因为数据直接体现在URL中了。但我们不能说POST方法比GET安全，只能说相比而言更私密，POST本质是明文传送，始终能够被抓包、提取数据。要想安全就一定是要加密，也就是HTTPS。
2.网页管理
（1）网页的权限管理
当我们访问VIP网站的时候，就算把URL分享出去，别人也是访问不进来的，为什么？
对于VIP网站设计者来说是肯定要做权限管理的，它根据用户是从哪里点进这个网站这件事就能筛掉一大批人；或者当没有从规定网站跳转进VIP网站时，就自动跳转到登录界面。
要实现这个很简单，请求端访问网站时会带上请求报头Referer，如Referer: https://www.baidu.com，当服务端收到这个报头时就判断对方是非法访问，就会选择拒绝回应或者直接跳转到登录界面。因此就实现了网页的权限管理。
（2）临时重定向和永久重定向
重定向有风险，重定向次数过多会失败，要慎用
①永久重定向（301）
比较广为人知的一个消息就是twitter改名为X，那么twitter的网站域名就要发生改变，不再是www.twitter.com了。但直接改会出现大量问题，原先的twitter积累的大量的用户，一下子改网址显然会引起很大的波动，每个人都需要改变自己的习惯，重定向就让这个过程更加温和。
永久重定向就像搬家，永远不会回来了，IP也会变。那么如果有人要拜访我家，我就需要在原来的家门口插上一块牌子，写着我的新地址。网址也是如此，当访问old.com时，会有各种途径（比较复杂）响应请求方状态码为301，并且请求报头里面带有Location: new.com，这个时候客户端浏览器会马上重定向，访问new.com，这样就实现了温和的网址替换。一般Location都要带新地址的全路径，如果只是相对路径的修改当然也可以只写相对路径。
在这个过程中，浏览器也很灵活，当收到301之后，它就会缓存这个新地址。当后续再访问old.com时，浏览器就不走原来重定向那条路了，它会直接访问new.com。因为是“永久”重定向，所以浏览器会做这种大胆的事情。
②临时重定向（302）
临时重定向就像旅游，住几天酒店还会回来。那么这个时候家门口也要插块牌子，写着自己去旅游去了，地址在哪（和永久重定向一样）。当请求端收到302和Location之后，也会自动再次访问新的地址。注意对于301还是302，跳转的含义都是指的客户端再次发起请求，服务端不会跳转的，它只会告诉客户端下一步怎么做。
唯一的区别就是浏览器不会缓存301定位的地址，对方随时会回来，浏览器自然不敢像永久重定向那样替别人做决定。
（3）cookie
①会话保持
网页上第一次打开b站要登录，但短时间内第二次打开就不需要了。这是因为服务器第一次认证用户和密码，认证之后就会返回一些内容，写到客户端浏览器的某个位置。第二次访问时，浏览器就会把上次服务器返回的信息自动携带上，这部分内容就是cookie。cookie保存在本地，可能是内存级（退出浏览器就清空）也可能是文件级（磁盘级保存），不同浏览器有不同策略。
删掉cookie后我们访问b站就需要再次登录了。因此，cookie可以帮助服务器每次都认识我们，这就是基于cookie的会话保持功能。
更加具体地说，登录后服务器的应答中包含Set-Cookie报头，里面有我们的用户名和密码等信息，客户端浏览器会将这个报头的信息写入cookie，之后每次请求登录时都会带上cookie。因此，服务器只要得到了这个认证信息，就认识客户端。通过cookie，各大视频网站也能实现试看五分钟了，你会发现试看前都要求登录，登录之后只要访问试看视频资源时，客户端就会上传自己的cookie，服务器就一定能认识客户端，从而形成时间控制。
②cookie的隐私泄露问题
HTTP是无连接、无状态的，直接发起请求和回应。无连接是因为有连接的部分都交给TCP来做了，HTTP直接负责从TCP缓冲区那里获取信息，而这个获取的过程是无连接的。无状态体现在HTTP不知道我们多久前访问过网站，TCP释放就释放了，没有记录。因此，面对HTTP的这种无状态特性，才有了让cookie携带用户信息这种事情。否则根据HTTP的无状态特性，每次访问都需要重新登录，这让人感到很不方便。
但是cookie是把双刃剑，如果电脑中病毒，cookie文件被窃取的话就会导致隐私泄露，身份泄露，犯罪分子利用我们的cookie就有可能造成服务端错认身份，错认犯罪分子为账号主人。因此光有cookie是完全不够的。
③session
session就是应对cookie泄露的一个方法。每当服务端认证登录之后，就会在服务器上形成一个新的session对象，包含用户的账号密码等私密信息，这个对象也会对应唯一的session_id。
登录后，服务器应答中的Set-Cookie里保存的就是session_id了，客户端收到后同样写入cookie中，后续客户端访问服务器携带的就只是session_id了，这样用户私密信息不会泄露。
但其实这样也避免不了cookie信息被盗取，只是相对更安全，私密信息始终是在服务端的，大公司都有自己的安全团队，加上各种法律约束，所以被黑的风险小。除此外，服务端还可以设计各种策略来防止黑客的恶意操作。比如前一秒人在上海，下一秒就在缅北，遇到这种情况，服务器会直接让session_id失效；服务器也可以对用户的浏览行为监视实现判断。
安全问题需要技术、法律共同约束，世上没有完美的安全技术。
3.搜索引擎
（1）搜索引擎和浏览器的关系
浏览器可以认为是一个壳子，而壳子下的内核是搜索引擎。对于大部分用户而言，使用什么浏览器就决定他们会使用什么搜索引擎（有的浏览器支持修改搜索引擎），所以对互联网厂商而言，浏览器就是自己的门面，非常重要。
在电脑发展早期，人们都是通过上网来获取资源，App没有现在这么多。因此用户电脑上使用什么搜索引擎就是各个厂商的竞争点。但是搜索引擎是个大工程，也需要海量数据来构建，这需要巨大的资金，所以很多公司都选择先做浏览器，把自家浏览器、品牌推广出去，后面再做出自己的搜索引擎。简单来说，浏览器是入口，只有推广了入口，后面自家的搜索引擎才能用起来。这就是电脑发展早期我们至少能见到几十上百种浏览器的原因。
各家都疯狂推出自己的浏览器，因此浏览器的标准争夺非常剧烈，每家都有自己的一面之词，都不甘服从别的公司的标准，这也造就了当今状态码使用分歧很大，就像前面说的状态码200，但返回404.html一样。
（2）搜索引擎的构建和更新
搜索引擎可以用HTTP协议爬取网页，即针对一个网页发起请求并得到网页返回，再对网页文本进行分析，再从分析的文本种得到新的网址，再访问......这样就能把一个网址里面的所有内容全部爬取，再通过分词得到大量的关键字文本，建立自己的搜索方案。这样网页的链接就能和网页里面的内容关联起来，用户就可以根据关键字搜索网页。搜索引擎可以帮助推广，这里面也有商业模式。
一旦更新域名，网址就可能直接失效。但搜索引擎会定期更新爬取，自动更新网址，这样用户搜的时候就能直接跳转。所以301不仅给了温和的换域名适应方案，还能帮助搜索引擎更新网址。
)
