求问一下手机怎么解决用抓包软件 抓包软件出现307 Temporary Redirect这个问题?

HTTP问题简单,那就直接列举几个问题,有些问题我给出详细答案。

有一点需要特别注意,有的浏览器是不支持的,所以在使用和实现时需要仔细评估好自己客户端的能力。

那么OPTIONS一般用在哪里呢?是的,CORS。如果您开发过SPA,或者您的前端的逻辑和交互完全用JavaScript来实现的,肯定会碰到此问题。所谓JavaScript实现,目前比交流行的有VueJS,AngularJS,React等流行框架。如何解决这个问题?最常用的方法是是前端和后端在同一个域名下。如果不在同一个域名下,需要在后端实现支持CORS的功能,目前Spring/Spring Boot已经有类似功能支持CORS,实现起来蛮简单的,具体可以参看 ,不在赘述。

关于CORS,最难的不是这里,在我遇到的Case里,比这个更复杂,如果前端是SPA,而且在某种情况下,访问任何前端页面都会进行跳转,这是需求。但是因为是SPA的架构,会出现OPTIONS(这是浏览器关于CORS支持的流程),这会使整个HTTP 流程变得紊乱,也是一个很棘手的问题。

不管怎么说,CORS属于安全性这一块,后面在软件安全(包括Web)方面专门写吧。在过去几年里,因为公司和客户在产品安全和数据安全放在了一个很高的位置,而我又是去负责这一块,所以自己在安全方面积累了大量的实战经验,非常宝贵。

server的值是squid/3.5.24,不合适之处在哪里?也许部分人是不清楚的。其实很简单,不应该把squid的版本信息放在这里。为什么?

如果web server软件是自己公司开发的,私有的,不开源的,这也罢了,没人知道你的web server是怎么实现的,但这并不代表web  server没有漏洞,不代表别人发现不了漏洞。

但如果用的是开源的,例如Apache HTTPd,Apache Tomcat,Ngnix等,就需要注意了,每个版本都有安全漏洞,而且这些安全漏洞都有专门的记录,看看隔三差五报告的CVE,就知道漏洞多少了。所以,如果使用开源软件,很容易将自己的web server处于一个具有潜在风险的位置,所以不要加上版本号。

腾讯作为全球顶级的大公司,这方面不注意,实在是有点说不过去。如果有腾讯的朋友看到这里,还是改过来吧。

和上面一样,这也是属于安全性问题,有时间我再写吧。

都属于跳转,但是区别在哪里呢?

我们看看307在协议里是怎么定义的?参看rfc2616第10章节

在 GET、HEAD 这些幂等的请求方式上,302、307 没区别,但对于 POST 就不同了,大部分浏览器 都会 302 会将 POST 请求转为 GET,而 307则不一样,规范要求浏览器继续向 Location 的地址 POST 内容。

举个例子解释一下,假设正在POST一个消息,里面的Body有1M内容,在307的情况下,这1M的内容会继续发过去,但在302的情况下,则不会。

不解释过多,keep-alive,closed用法不一样,根据实际情况而定,在优化网络时经常用到。

需要注意的是,Connection在通信领域会一些场景下会造成一些麻烦,尤其是在监控某个HTTP Session的flow时。

HSTS一般大公司都会用,在我实际的项目涉及到HTTPS,为了实现某个功能,HSTS成了一个跨不过去的坎,遇到过很大问题。大家自己多看看吧。

8. 可以抓HTTPS的包了解HTTP请求和响应吗?有什么方法?

9. 为什么对性能要求高的场景下不使用HTTP作为协议?例如在商用里,RPC开源项目一般不使用HTTP作为传输协议?而在5G下使用HTTP协议呢?

有一点是需要注意的,HTTP的消息头太多了,会造成消息体特别大,影响性能,而且有些场景下这些消息头大部分都是无用的。

不多解释,但是HTTP/2.0还是需要了解一下,优势和缺点。

现在浏览器接收到了server的返回内容,接下来浏览器该把内容呈现给用户了。

Server返回的内容有哪些呢?这里只以HTML页面为例(API返回的JSON数据或XML数据不在讨论范围内)。

一个页面一般包含HTML、CSS、 JS、 图片等文件,那么浏览器收到这些文件后该如何渲染(render)他们呢?

以下部分很多参考下面2篇文章:

首先我们先了解一下浏览器的组件构成,以及每个组件的功能,下图是浏览器包括的几个部分:

  1. User Interface: UI组件包括地址栏,前进/后退按钮,书签菜单等。
  2. Rendering engine : 负责显示请求的内容。例如,如果是HTML页面,它将解析HTML,CSS,并将解析的内容显示在屏幕上。

不同的浏览器使用不同的渲染引擎:

下面是浏览器的渲染引擎的主要步骤。

渲染引擎解析HTML文档,并将HTML包含的元素转化为一个个DOM,并构建为一个 DOM树。然后引擎开始解析来自CSS文件或直接嵌在HTML页面的CSS样式数据,这些样式信息又会构建另外一个树: 渲染树

渲染树包含了多个矩形,这些矩形包含了颜色,大小,位置等属性,而且会按照对应的顺序显示在屏幕上。

当渲染树构造完毕后,接下来进入布局的程序,在这个程序里,渲染引擎会给每个DOM元素安排精确的坐标,并根据坐标在屏幕上显示。

接下来是遍历渲染树,UI Backend层会将一个个DOM元素绘画在屏幕上绘画出来。

需要注意的是,上面是一个渐进的过程,理解这一点非常重要。但是为了得到更好的用户体验,浏览器会边解析边渲染,它并不会等到所有HTML解析完了才开始构造和布局渲染树。当部分内容正在解析渲染时,另外一部分正从网络那边下载下来呢。

下面2个图是WebKit和Gecko的渲染引擎的流程,我们发现他们大致相同的。

下面是DOM树,渲染树的树形结构。

渲染引擎是单线程工作的,除了网络操作,其他所有的都是单线程的。在Firefox和Safari,它们自己就是主线程,而Chrome就是每个tab处理主线程。

网络操作则由多个并列线程去执行,但数量也是受限的,一般在2-6个。

浏览器的主线程是一个无限的事件循环,而且一直保持进程alive,一直等着各种事件(例如绘画事件,布局事件),并处理他们。

2.  各个主流浏览器的渲染引起是什么?

3.  浏览器显示页面的主要流程是什么?

4.  您在做开发和测试时,有哪些浏览器(包括手机)存在兼容性问题较多?

       遇见最多的是Samsung手机和Huawei手机,有时一个兼容性需要花费大量时间去调研和修复,可能是Samsung和Huawei定制的太厉害了,不兼容一些特性吧。

5.  渲染引擎是单线程还是多线程?

6.  浏览器的网络操作一般由几个线程去执行?

8.  为了获得更好的用户体验,我们应该在页面做些什么改进?

10. 如果让你开发一个浏览器,设计思路有哪些?

我们知道,人的耐心是有限的,一个页面如果超过8s,人基本上不会等了,这会对业务产生巨大影响。我们该如何去优化页面呢?

思路很简单,就是按照我们前面介绍的几大步骤去优化。我们先回顾一下几大步骤:

这是10多年前的经验,随着科技的发展,一些新的经验又出现了,可以容易想到的是:

1.  尽量将server离用户近一些,例如人处在中国访问Apple,应该是Apple中国站提供服务,GSLB很重要。

2. 不要把layout嵌入一层又一层,简单说就是嵌套别太深,不然影响解析和渲染性能。

3. 有些数据可以在后台处理的,就不要在前端通过JavaScript处理了。

4. 如果请求过大,Load Balance这些手段还是要上的。

6. 后台事件性能要高,能够及时将结果返回给用户。

当然涉及到高可用,高性能等那是另外一个话题。

这道面试题非常经典,考察的知识非常丰富,跨度较大,如果没有几年的经验,是很难完全掌握的,所以想答好其实不容易的。对这个问题,基本上可以根据我的经验回答,也算是对这些年来在这方面的知识的一个总结。但同时,我也参考了一些资料,感谢他们。在参考的地方,我都把URL列出来了。

写这篇文章耗费了大量时间,我觉得挺有意义,但是也不能保证里面的内容全都是正确或准确的,如果您有任何问题可以通过以下方式联系我,以便我进一步改正并更新。

写到这里,三部分已经写完,在这里放上全文的PDF文档供大家参考,可能后面会更改,如果有新的文档,我将保持更新。

为了避免很多小白进来看到这个问题一脸蒙圈,我想做一个完整的补充。老杨的文章一向是以详细(废话多)出名的,所以,看了开头就觉得好的速度收藏起来看,保证给你搞懂。

周五了,老杨写完回答就准备去海底捞吃顿夜宵去。

1、网络工程师面试时,到底要怎么回答一个问题?

其实很多时候,新手网工在接受面试时会有这种困惑:当面试官问你技术问题的时候,他到底是在问你什么?

比如,面试官问了你一个OSPF。你觉得,面试官是想听你说OSPF协议的内容或者是字段吗?这种照本宣科的东西,面试里就不太适用了,职场并不是理论考试。

他们关心你的项目经验。

比如,问你知道OSPF是什么的时候,你不仅能回答出是什么,还能说出之前自己经手的项目中部署过它,遇到了什么问题,实际情况是怎样的,最后如何解决的……那你收到offer的概率就大幅度提升了。

比起纸上谈兵,面试更需要的是你的“真刀真枪”。

“真刀真枪”包括并不限于排错思路、维护客户、售后基础、项目细节等等等等,根据岗位要求不同,难度会有不同程度的增减。

很多专注于快速考过各类IE的同学往往忽视了这些细节,只注重我到底拿下了几本证书,到头来面试官一问,全都一脸懵逼,这就是典型的本末倒置。

明明学习过程里并不只有理论,为何面试时只达理论,却不告知面试官自己对于这个东西的理解和思考呢?

2、面试中被问到计算机网络状态码,你会怎么回答?

为了让小白和萌新更好阅读,老杨把问题拆解一下:首先要讲讲什么是HTTP,再讲讲什么是计算机网络HTTP的状态码,讲讲302和303会出现在什么场景里,以此来判断二者的区别。

(1)什么是HTTP?

HTTP(Hypertext Transfer Protocol)超文本传输协议是一个简单的请求 - 响应协议,是个应用层的协议,准确来说是一种协议规范。

它被运用于客户端和服务器中间的通信。你看,客户端程序和服务器程序通过交换 HTTP 报文进行会话,HTTP 就在这个过程里定义了这些报文的结构以及客户和服务器进行报文交换的方式。

简单来说,它的作用就是拿来规定客户端发送给服务器什么模样的消息,以及能获得什么模样的响应。

它是咋出现的呢?那我们就要讲到万维网(World Wide Web,WWW)了。万维网的出现和发展背后,有一大堆网络协议和标准支持,他们是我web协议族,里面就包含了HTTP超文本传输协议。

因为不同的发展阶段,就代表了不同的网络状态码的解读,先提一下,下面继续讲。

(2)什么是计算机网络HTTP的状态码?

HTTP状态码(HTTP Status Code)是用以表示网页服务器超文本传输协议响应状态的3位数字代码。所有状态码的第一个数字就代表了响应的五种状态之一。

响应的五种状态分别是:信息响应(100–199),成功响应(200–299),重定向(300–399),客户端错误(400–499)和服务器错误 (500–599)。

从上述的五种状态,你就可以看出,这类状态码一般显示三位数,比如问题里的“302”“303”和大家比较悉知的“404”这样的数字,这些数字对应不同的网络状态,有好有坏。

那3xx,就代表了“重定向”,表示你想要它完成你的要求,就要进行更进一步的操作才可以。

假设你现在在使用电脑浏览器登录某平台,现在很多平台不注册账号密码都不让你浏览,对吧?

那你想要浏览,就得登录填写帐号、密码,再点击登录按钮。

如果你的帐号密码正确,就自动跳转到平台首页浏览,如果不正确就返回登录页重新登录。这里的“自动跳转”,就是“重定向”的意思。

即:设置一个约束条件,条件满足,就自动转入到对应页面,如果条件不满足,就重新回到原网页,让你继续操作,直至正确,这就是“重定向”。

(3)计算机网络状态码302和303是什么意思?

从上一点我们可以知道,3xx开头的状态码意味着“重定向”。那既然都是重定向,302和303的区别是啥?

老杨在上面还讲了一点,就是HTTP的发展。我们就根据这个来判断二者区别。

文档规定:第一次请求得到 302 响应,浏览器询问用户是否以同样的 Method 向新 URL 发送请求。

在浏览器实现上,为遵循幂等原则,若用户第一次为 POST 请求,浏览器询问用户是否向新 URL 发送请求,并强制使用 GET发送第二个请求(与文档规定有所差异)。

在http1.1 协议之后的补充时期:

为了弥补 http1.0 时期文档中 302 和浏览器实现上 302 的偏差,这才逐渐补充了303和307的状态码。

301和302在HTTP里规定了要以原谓词重新发起新的重定向请求,但实际操作中,不管第一次是什么谓词,重定向后都变成Get,为了不造成兼容问题,所以就留着这个错误继续发展了。

之后啊,发现这个问题得解决了,这才出现了303/307。

所以302和303是先后的补充关系。

303的意思是:迎合幂等原则,使用上边第二点的处理流程。当第一次请求响应码为 POST,询问用户,第二次以 GET 向新 URL 发送请求。

307的意思是:为原文档规定的 302 处理方法。第一次第二次请求的 Method 不能有变。

就像楼上的一个回答说的那样,简单来说,http 1.0时的302具有二义性,所以在http 1.1之后加入303和307就是为了消除302的二义性。

3、还有其他的网络状态码,都是个什么含义?

这个临时响应表明,迄今为止的所有内容都是可行的,客户端应该继续请求,如果已经完成,则忽略它。

该代码是响应客户端的 Upgrade (en-US) 标头发送的,并且指示服务器也正在切换的协议。

此代码表示服务器已收到并正在处理该请求,但没有响应可用。

此状态代码主要用于与Link 链接头一起使用,以允许用户代理在服务器仍在准备响应时开始预加载资源。

请求成功。成功的含义取决于HTTP方法:

GET:资源已被提取并在消息正文中传输。

HEAD:实体标头位于消息正文中。

POST:描述动作结果的资源在消息体中传输。

TRACE:消息正文包含服务器收到的请求消息

该请求已成功,并因此创建了一个新的资源。这通常是在POST请求,或是某些PUT请求之后返回的响应。

请求已经接收到,但还未响应,没有结果。意味着不会有一个异步的响应去表明当前请求的结果,预期另外的进程和服务去处理请求,或者批处理。

服务器已成功处理了请求,但返回的实体头部元信息不是在原始服务器上有效的确定集合,而是来自本地或者第三方的拷贝。当前的信息可能是原始版本的子集或者超集。例如,包含资源的元数据可能导致原始服务器知道元信息的超集。使用此状态码不是必须的,而且只有在响应不使用此状态码便会返回200 OK的情况下才是合适的。

服务器成功处理了请求,但不需要返回任何实体内容,并且希望返回更新了的元信息。响应可能通过实体头部的形式,返回新的或更新后的元信息。如果存在这些头部信息,则应当与所请求的变量相呼应。如果客户端是浏览器的话,那么用户浏览器应保留发送了该请求的页面,而不产生任何文档视图上的变化,即使按照规范新的或更新后的元信息应当被应用到用户浏览器活动视图中的文档。由于204响应被禁止包含任何消息体,因此它始终以消息头后的第一个空行结尾。

服务器成功处理了请求,且没有返回任何内容。但是与204响应不同,返回此状态码的响应要求请求者重置文档视图。该响应主要是被用于接受用户输入后,立即重置表单,以便用户能够轻松地开始另一次输入。与204响应一样,该响应也被禁止包含任何消息体,且以消息头后的第一个空行结束。

服务器已经成功处理了部分 GET 请求。类似于 FlashGet 或者迅雷这类的 HTTP 下载工具都是使用此类响应实现断点续传或者将一个大文档分解为多个下载段同时下载。该请求必须包含 Range 头信息来指示客户端希望得到的内容范围,并且可能包含 If-Range 来作为请求条件。

由WebDAV(RFC 2518)扩展的状态码,代表之后的消息体将是一个XML消息,并且可能依照之前子请求数量的不同,包含一系列独立的响应代码。

在 DAV 里面使用: propstat 响应元素以避免重复枚举多个绑定的内部成员到同一个集合。

服务器已经完成了对资源的 GET 请求,并且响应是对当前实例应用的一个或多个实例操作结果的表示。

被请求的资源有一系列可供选择的回馈信息,每个都有自己特定的地址和浏览器驱动的商议信息。用户或浏览器能够自行选择一个首选的地址进行重定向。

被请求的资源已永久移动到新位置,并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。如果可能,拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定,否则这个响应也是可缓存的。

请求的资源现在临时从不同的 URI 响应请求。由于这样的重定向是临时的,客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下,这个响应才是可缓存的。

对应当前请求的响应可以在另一个 URI 上被找到,而且客户端应当采用 GET 的方式访问那个资源。这个方法的存在主要是为了允许由脚本激活的POST请求输出重定向到一个新的资源。

如果客户端发送了一个带条件的 GET 请求且该请求已被允许,而文档的内容(自上次访问以来或者根据请求的条件)并没有改变,则服务器应当返回这个状态码。304 响应禁止包含消息体,因此始终以消息头后的第一个空行结尾。

被请求的资源必须通过指定的代理才能被访问。Location 域中将给出指定的代理所在的 URI 信息,接收者需要重复发送一个单独的请求,通过这个代理才能访问相应资源。只有原始服务器才能建立305响应。

在最新版的规范中,306 状态码已经不再被使用。

请求的资源现在临时从不同的URI 响应请求。由于这样的重定向是临时的,客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下,这个响应才是可缓存的。

这意味着资源现在永久位于由 Location: HTTP Response 标头指定的另一个 URI。这与 301 Moved Permanently HTTP 响应代码具有相同的语义,但用户代理不能更改所使用的 HTTP 方法:如果在第一个请求中使用 POST,则必须在第二个请求中使用 POST。

  • 语义有误,当前请求无法被服务器理解。除非进行修改,否则客户端不应该重复提交这个请求。

当前请求需要用户验证。该响应必须包含一个适用于被请求资源的 WWW-Authenticate 信息头用以询问用户信息。客户端可以重复提交一个包含恰当的 Authorization 头信息的请求。如果当前请求已经包含了 Authorization 证书,那么401响应代表着服务器验证已经拒绝了那些证书。如果401响应包含了与前一个响应相同的身份验证询问,且浏览器已经至少尝试了一次验证,那么浏览器应当向用户展示响应中包含的实体信息,因为这个实体信息中可能包含了相关诊断信息。

此响应码保留以便将来使用,创造此响应码的最初目的是用于数字支付系统,然而现在并未使用。

服务器已经理解请求,但是拒绝执行它。与 401 响应不同的是,身份验证并不能提供任何帮助,而且这个请求也不应该被重复提交。如果这不是一个 HEAD 请求,而且服务器希望能够讲清楚为何请求不能被执行,那么就应该在实体内描述拒绝的原因。当然服务器也可以返回一个 404 响应,假如它不希望让客户端获得任何信息。

请求失败,请求所希望得到的资源未被在服务器上发现。没有信息能够告诉用户这个状况到底是暂时的还是永久的。假如服务器知道情况的话,应当使用410状态码来告知旧资源因为某些内部的配置机制问题,已经永久的不可用,而且没有任何可以跳转的地址。404这个状态码被广泛应用于当服务器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下。

请求行中指定的请求方法不能被用于请求相应的资源。该响应必须返回一个Allow 头信息用以表示出当前资源能够接受的请求方法的列表。鉴于 PUT,DELETE 方法会对服务器上的资源进行写操作,因而绝大部分的网页服务器都不支持或者在默认配置下不允许上述请求方法,对于此类请求均会返回405错误。

请求的资源的内容特性无法满足请求头中的条件,因而无法生成响应实体。

与401响应类似,只不过客户端必须在代理服务器上进行身份验证。代理服务器必须返回一个 Proxy-Authenticate 用以进行身份询问。客户端可以返回一个 Proxy-Authorization 信息头用以验证。

请求超时。客户端没有在服务器预备等待的时间内完成一个请求的发送。客户端可以随时再次提交这一请求而无需进行任何更改。

由于和被请求的资源的当前状态之间存在冲突,请求无法完成。这个代码只允许用在这样的情况下才能被使用:用户被认为能够解决冲突,并且会重新提交新的请求。该响应应当包含足够的信息以便用户发现冲突的源头。

被请求的资源在服务器上已经不再可用,而且没有任何已知的转发地址。这样的状况应当被认为是永久性的。如果可能,拥有链接编辑功能的客户端应当在获得用户许可后删除所有指向这个地址的引用。如果服务器不知道或者无法确定这个状况是否是永久的,那么就应该使用 404 状态码。除非额外说明,否则这个响应是可缓存的。

服务器拒绝在没有定义 Content-Length 头的情况下接受请求。在添加了表明请求消息体长度的有效 Content-Length 头之后,客户端可以再次提交该请求。

服务器在验证在请求的头字段中给出先决条件时,没能满足其中的一个或多个。这个状态码允许客户端在获取资源时在请求的元信息(请求头字段数据)中设置先决条件,以此避免该请求方法被应用到其希望的内容以外的资源上。

服务器拒绝处理当前请求,因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。此种情况下,服务器可以关闭连接以免客户端继续发送此请求。如果这个状况是临时的,服务器应当返回一个 Retry-After 的响应头,以告知客户端可以在多少时间以后重新尝试。

请求的URI 长度超过了服务器能够解释的长度,因此服务器拒绝对该请求提供服务。这比较少见,通常的情况包括:本应使用POST方法的表单提交变成了GET方法,导致查询字符串(Query String)过长。

对于当前请求的方法和所请求的资源,请求中提交的实体并不是服务器中所支持的格式,因此请求被拒绝。

如果请求中包含了 Range 请求头,并且 Range 中指定的任何数据范围都与当前资源的可用范围不重合,同时请求中又没有定义 If-Range 请求头,那么服务器就应当返回416状态码。

此响应代码意味着服务器无法满足 Expect 请求标头字段指示的期望值。

服务器拒绝尝试用 “茶壶冲泡咖啡”。

该请求针对的是无法产生响应的服务器。这可以由服务器发送,该服务器未配置为针对包含在请求 URI 中的方案和权限的组合产生响应。

请求格式良好,但由于语义错误而无法遵循。

正在访问的资源被锁定。

由于先前的请求失败,所以此次请求失败。

服务器不愿意冒着风险去处理可能重播的请求。

服务器拒绝使用当前协议执行请求,但可能在客户机升级到其他协议后愿意这样做。服务器在 426 响应中发送 Upgrade (en-US) 头以指示所需的协议。

原始服务器要求该请求是有条件的。旨在防止“丢失更新”问题,即客户端获取资源状态,修改该状态并将其返回服务器,同时第三方修改服务器上的状态,从而导致冲突。

用户在给定的时间内发送了太多请求(“限制请求速率”)。

服务器不愿意处理请求,因为它的 请求头字段太大( Request Header Fields Too Large)。请求可以在减小请求头字段的大小后重新提交。

用户请求非法资源,例如:由政府审查的网页。

服务器遇到了不知道如何处理的情况。

此请求方法不被服务器支持且无法被处理。只有GET和HEAD是要求服务器支持的,它们必定不会返回此错误代码。

此错误响应表明服务器作为网关需要得到一个处理这个请求的响应,但是得到一个错误的响应。

服务器没有准备好处理请求。常见原因是服务器因维护或重载而停机。请注意,与此响应一起,应发送解释问题的用户友好页面。这个响应应该用于临时条件和 Retry-After:如果可能的话,HTTP头应该包含恢复服务之前的估计时间。网站管理员还必须注意与此响应一起发送的与缓存相关的标头,因为这些临时条件响应通常不应被缓存。

当服务器作为网关,不能及时得到响应时返回此错误代码。

服务器不支持请求中所使用的HTTP协议版本。

服务器有一个内部配置错误:对请求的透明内容协商导致循环引用。

服务器有内部配置错误:所选的变体资源被配置为参与透明内容协商本身,因此不是协商过程中的适当端点。

服务器在处理请求时检测到无限循环。

客户端需要对请求进一步扩展,服务器才能实现它。服务器会回复客户端发出扩展请求所需的所有信息。

511 状态码指示客户端需要进行身份验证才能获得网络访问权限。

4、想要熟悉网络,能推荐个一本就能搞定的书吗?

对于小白和行外人,非要我推荐一本,我选《计算机网络-自顶向下方法》第7版,陈鸣翻译的那本。

这本书算是小白读都很通俗易懂的书了,很多原理不仅让你知道是什么,还让你知道为什么,并且告诉你要怎么运用。这对于小白来说是记忆最好的方法。

还想要看什么技术问题,欢迎评论区告诉我哈。

原创: 老杨丨8年资深网络工程师,更多网工提升干货,请关注公众号:网络工程师俱乐部

F12中的XHR全部是接口

5.get请求的缺点?(以及与post的真正的区别)

1.请求信息暴露在url中,不利于信息的安全 ,post抓包工具就能抓到,其实也不是很安全的

2.url很长,不是很美观

3.但是传输速度大于post请求

4.post的传参个数较大,get传参个数相对较少

5.对于GET方式的请求,浏览器会把http header和data一并发送出去,服务器响应200(返回数据);

而对于POST,浏览器先发送header,服务器响应100 continue,浏览器再发送data,服务器响应200 ok(返回数据)

我要回帖

更多关于 模拟器抓包有些app抓不到 的文章

 

随机推荐