【计算机网络】八股文 | 第一章
零、前言
一、计算机网络层次结构
1. 计算机网络层次结构有哪些模型,区别?
2. 介绍一下OSI体系结构
3. 介绍一下TCP/IP五层体系结构
4. 简单说下每一层对应的网络协议有哪些
二、应用层之HTTP协议、URL/URI
1. 什么是HTTP协议
2. HTTP协议的优点与缺点
3. HTTP协议的性能
4. URL/URI区别
5. URL有哪些组成部分
6. 为什么说HTTP协议是无状态协议?
7. 怎么解决HTTP协议无状态协议? Cookie/Session
三、应用层之HTTP请求,响应,状态码
0. HTTP报文的构成(知识点)
1. HTTP请求报文的是什么样的?
2. HTTP响应报文的是什么样的?
3. 常见的HTTP首部字段?请求头和响应头?
4. HTTP状态码
5. HTTP状态码304【是多好还是少好】
6. 同样是重定向,301,302,303和307之间的区别?
四、应用层之HTTP请求方法
0. 各种请求的简单介绍(知识点,非考题)
1. HTTP请求方法有哪些
2. POST和GET有哪些区别?各自应用场景?
3. POST和PUT请求的区别
4. GET方法URL长度限制的原因
5. GET请求中URL编码的意义
6. POST请求什么时候是两次什么时候是一次
7. POST 请求什么时候用 form data 什么时候用 request payload
8. OPTIONS请求方法及使用场景
下一章笔记
零、前言
这里放一下自己之前做的八股文笔记,会不定期更新。下面是我做的笔记的一个展示。这里第一章就先更新其中一部分吧。 下面部分图来源于之前看的博客及视频,之前做笔记没有记录来源,如果知道可以留,我把链接放上。
一、计算机网络层次结构
1. 计算机网络层次结构有哪些模型,区别?
1️⃣OSI的七层体系结构
从下往上依次为物理层、数据链路层、网络层、运输层、会话层、表示层、应用层。
2️⃣TCP/IP的四层体系结构
从下往上依次为网络接口层、网际层、运输层、应用层。
3️⃣五层协议的原理体系结构(主要用于教学和学习)
从下往上依次为物理层、数据链路层、网络层、运输层、应用层。
2. 介绍一下OSI体系结构
OSI的七层体系结构:
从下往上依次为物理层、数据链路层、网络层、运输层、会话层、表示层、应用层。
物理层:底层数据传输,如网线;网卡标准,采用怎样的传输媒质,采用怎样的物理接口,采用怎样的信号表示比特0/1。通过物理介质传输比特流。规定了电平、速度和电缆针脚。常用设备有(各种物理设备)集线器、中继器、调制解调器、网线、双绞线、同轴电缆。
数据链路层:定义数据的基本格式,如何传输,如何标识;如网卡MAC地址。将比特组合成字节,再将字节组合成帧,使用链路层地址 (以太网使用MAC地址)来访问介质,并进行差错检测。
网络层:定义IP编址,定义路由功能;如不同设备的数据转发。通过IP
寻址来建立两个节点之间的连接,为源端的运输层送来的分组,选择合适的路由和交换节点,正确无误地按照地址传送给目的端的运输层。路由器和网络交换机工作在此层。
传输层:建立了主机端到端的链接,传输层的作用是为上层协议提供端到端的可靠和透明的数据传输服务,包括处理差错控制和流量控制等问题。端到端传输数据的基本功能;如TCP、UDP
。
会话层:负责建立、管理和终止表示层实体之间的通信会话。该层的通信由不同设备中的应用程序之间的服务请求和响应组成。控制应用程序之间会话能力;如不同软件数据分发给不同软件。
表示层:提供各种用于应用层数据的编码和转换功能,确保一个系统的应用层发送的数据能被另一个系统的应用层识别。数据格式标识,基本压缩加密功能。base64
一般来说工作在表示层。
应用层:为计算机用户提供应用接口,也为用户直接提供各种网络服务。常见应用层的网络服务协议有:HTTP
,HTTPS
,FTP
,POP3
、SMTP
等。
3. 介绍一下TCP/IP五层体系结构
TCP/IP的四层体系结构:
从下往上依次为网络接口层、网际层、运输层、应用层。
物理层:将数据转化为比特流,确保数据可以在各种物理媒介上进行传输,为数据的传输提供可靠的环境。
数据链路层:负责将网络层交下来的 IP 数据报封装成帧,并在链路的两个相邻节点间传送帧,每一帧都包含数据和必要的控制信息(如同步信息、地址信息、差错控制等)。
网络层:有时也译为网际层,它负责为两台主机提供通信服务,并通过选择合适的路由将数据传递到目标主机。
传输层:有时也译为运输层,它负责为两台主机中的进程提供通信服务。
应用层:为计算机用户提供应用接口,也为用户直接提供各种网络服务。直接为应用进程提供服务。应用层协议定义的是应用进程间通讯和交互的规则,不同的应用有着不同的应用层协议。
数据形式的不同
设备的不同
协议的不同
应用层:超文本传输协议:HTTP,HyperText Transfer Protocol
;文件传输协议:FTP,File Transfer Protocol
;域名系统:DNS,Domain Name System
;安全外壳协议:SSH,Secure Shell
;动态主机配置协议:DHCP,Dynamic Host Configuration Protocol
;远程登录协议:TELNET
;
传输层:传输控制协议(面向连接,可靠传输):TCP,Transmission Control Protocol
;用户数据报文协议(无连接,不可靠):UDP,User Datagram Protocol
网络层:网际协议:IP,Internet Protocol
;地址转换协议:ARP,Address Resolution Protocol
;反地址转换协议:RARP,Reverse Address Resolution Protocol
;控制报文协议:ICMP,Internet Control Message Protocol
;网际组管理协议:IGMP,Internet Group Management Protocol
;路由信息协议:RIP,Routing Information Protocol
;路由器选择协议:OSPF,Open Shortest Path First
;边界网关协议:BGP,Border Gateway Protocol
数据链路层:自动重传请求协议:ARQ,Automatic Repeat-reQuest
;停止等待协议:CSMA/CD,Carrier Sense Multiple Access with Collision Detection
;点对点协议:PPP,Point to Point Protocol
4. 简单说下每一层对应的网络协议有哪些
应用层:超文本传输协议:HTTP,HyperText Transfer Protocol
;文件传输协议:FTP,File Transfer Protocol
;域名系统:DNS,Domain Name System
;安全外壳协议:SSH,Secure Shell
;动态主机配置协议:DHCP,Dynamic Host Configuration Protocol
;远程登录协议:TELNET
;
传输层:传输控制协议(面向连接,可靠传输):TCP,Transmission Control Protocol
;用户数据报文协议(无连接,不可靠):UDP,User Datagram Protocol
网络层:网际协议:IP,Internet Protocol
;地址转换协议:ARP,Address Resolution Protocol
;反地址转换协议:RARP,Reverse Address Resolution Protocol
;控制报文协议:ICMP,Internet Control Message Protocol
;网际组管理协议:IGMP,Internet Group Management Protocol
;路由信息协议:RIP,Routing Information Protocol
;路由器选择协议:OSPF,Open Shortest Path First
;边界网关协议:BGP,Border Gateway Protocol
数据链路层:自动重传请求协议:ARQ,Automatic Repeat-reQuest
;停止等待协议:CSMA/CD,Carrier Sense Multiple Access with Collision Detection
;点对点协议:PPP,Point to Point Protocol
二、应用层之HTTP协议、URL/URI
1. 什么是HTTP协议
HTTP(Hyper Text Transfer Protocol):HTTP 是超文本传输协议,它定义了客户端和服务器之间交换报文的格式和方式,是⼀个基于请求与响应,⽆状态的应用层协议,常基于TCP/IP协议传输数据,默认使用80 端口,是互联⽹上应⽤最为⼴泛的⼀种⽹络协议,所有的WWW(3W) ⽂件都必须遵守这个标准。 设计HTTP的初衷是为了提供⼀种发布和接收HTML页面的。方法
它使用 TCP 作为传输层协议,保证了数据传输的可性。 HTTP采用基于请求/响应模型的方式进行通信,是 Web 服务器与本地客户端之间传输超文本的应用层传送协议。其中,客户端向服务器发送 HTTP 请求,请求特定的资源,服务器然后发送HTTP响应消息,将请求的资源发送回客户端。在应用层中的数据称之为报文,所以HTTP协议对应的数据为HTTP报文。
根据模型通信方式,HTTP报文可以分为HTTP请求报文和HTTP响应报文。
HTTP链接:指用于连接 HTTP 服务器和客户端的通信线路。HTTP 链接通常使用 TCP 协议进行传输,TCP 协议是一种面向连接的协议,允许客户端和服务器建立可靠的连接。HTTP 链接使用端口号 80 来传输 HTTP 请求和响应消息,这意味着客户端和服务器之间的通信通常使用端口号 80 来标识。 TCP 协议提供了可靠的传输通道,HTTP 协议则利用 TCP 连接进行数据传输。
2. HTTP协议的优点与缺点
HTTP协议是一种非常简单的协议,它具有简单易用,灵活高效、传输速度快,可靠性较高,跨平台等优点,但也存在一些缺点,如不安全、不支持事务、不支持负载均衡,不支持并发连接,不可靠等。
HTTP协议是无连接,无状态,明文传输(但支持传输数据加密), 非事务性,只支持单个并发连接,支持多路复用,的协议,采用流式传输的方式,基于请求/响应模型、客户端 - 服务器通信。
HTTP协议具有以下优点 :
支持客户端/服务器模式
简单易用: HTTP 协议是一种非常简单的协议,只需要客户端和服务器之间的通信协议,不需要了解复杂的网络协议和网络拓扑结构。
灵活高效 :HTTP 允许传输任意类型的数据对象。正在传输的类型由 Content-Type 加以标记。HTTP 协议采用了流式传输的方式,可以将数据分成小的数据包进行传输,从而大大提高了传输效率。
无连接无状态,传输速度快 :HTTP 协议是无状态,无连接的协议,这里的状态是指通信过程的上下文信息。无连接就是限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接,采用这种方式可以节省传输时间
。
**跨平台:**HTTP 协议可以在不同的操作系统和计算机上运行,这使得它成为了一种跨平台的协议。
可靠性高 :HTTP 协议采用请求/响应模型,请求和响应报文之间有严格的时序关系,保证了数据传输的可靠性。
HTTP协议具有以下缺点 :
不安全: HTTP 协议是一种明文传输的协议,如果客户端和服务器之间的通信被黑客截获,那么黑客可以轻松地窃取通信数据,从而威胁客户端和服务器的安全。
不支持事务 :HTTP 协议是一种非事务性的协议,它不支持事务处理,这意味着客户端和服务器之间的通信不能同时进行。
不支持负载均衡 :HTTP 协议采用客户端/服务器模型,服务器需要直接响应客户端的请求,因此不支持负载均衡。
不支持并发连接 :HTTP 协议只支持单个并发连接,因此不适合处理高并发请求。
不可靠 :HTTP 协议是一种基于请求/响应模型的协议,它不能保证数据传输的可靠性。如果服务器发生故障或网络中断,客户端可能会收到错误的响应或丢失的数据。
3. HTTP协议的性能
HTTP 协议的性能受到多个因素的影响,包括以下几个方面:
请求和响应的长度:HTTP 请求和响应消息中的数据长度会增加传输时间,因此请求和响应消息越短,HTTP 协议的性能越好。
网络延迟:网络延迟是指从发送请求到接收到响应的时间。如果网络延迟较高,HTTP 协议的性能会下降。
服务器负载:如果服务器负载较高,HTTP 协议的性能也会下降。因为服务器需要处理更多的请求,所以响应时间会增加。
并发连接数:HTTP 协议的并发连接数取决于服务器和网络设备的处理能力。如果并发连接数过高,服务器可能会过热,从而影响 HTTP 协议的性能。
请求频率:如果 HTTP 请求的频率过高,服务器可能会陷入并发连接的困境,从而影响 HTTP 协议的性能。
总的来说,HTTP 协议的性能受到多种因素的影响,需要综合考虑。为了提高 HTTP 协议的性能,可以采取以下措施:
减少请求和响应的长度:可以通过压缩请求和响应消息中的数据来减少传输时间。
优化网络延迟:可以通过使用更快的网络连接或者优化网络路由来降低网络延迟。
减少服务器负载:可以通过减少并发连接数或者增加服务器的处理能力来降低服务器负载。
优化请求频率:可以通过减少 HTTP 请求的频率来降低请求频率。
4. URL/URI区别
URL 和 URI 都是用来定位资源的标识符
URI (Uniform Resource Identifier) 是一种标识符,用于唯一地标识互联网上的资源
URL (Uniform Resource Locator) 是 URI 的一种特定类型,它不仅仅标识了资源,还提供了如何访问该资源的方法
URL 是 URI 的一种形式。所有的 URL 都是 URI,但不是所有的 URI 都是 URL。如果一个 URI 只是用来标识资源,而没有指定如何访问该资源,那么它就是一个 URI,而不是 URL。
URL 是 URI 的一个子集,两者都定义了资源是什么,而 URL 还定义了如何能访问到该资源。URI 是一种语义上的抽象概念,可以是绝对的,也可以是相对的,而URL则必须提供足够的信息来定位,是绝对的。简单地说,只要能唯一标识资源的就是 URI,在 URI 的基础上给出其资源的访问方式的就是 URL。
5. URL有哪些组成部分
URL 指**“统一资源定位符”(Uniform Resource Locator)**,也就是我们常说的网址,通常由协议标识符、主机名(又称之为域名)、端口、路径、文件名、查询参数及锚点组成。其中:
协议标识符(scheme):指明浏览器请求服务器资源使用的协议。如HTTP,FTP,SMTP等。必要
主机名(host):资源所在的网站名或服务器的名字,又称为域名。eg. www.example.com
。有些主机没有域名,只有 IP 地址,比如192.168.2.15
。这种情况常常出现在局域网。必要
端口(port):紧跟在域名后面,两者之间使用冒号分隔,表示域名下网站的索引。端口不是一个URL必须的部分,如果省略端口部分,将采用默认端口(HTTP协议默认端口是80,HTTPS协议默认端口是443)。非必要
路径(path):资源在网站的位置,路径可能只包含目录,不包含文件名。非必要
文件名:从域名后的最后一个“/”开始到“?”为止,是文件名,指定了要访问的资源的文件名。如果省略该部分,则使用默认的文件名。非必要
查询参数(parameter):从“?”开始到“#”为止之间的部分为参数部分,又称搜索部分、查询部分。是提供给服务器的额外信息。查询参数可以有一组或多组。多组参数之间使用&
连接。每组参数都是键值对(key-value pair)的形式,同时具有键名(key)和键值(value),它们之间使用等号(=
)连接。比如,key1=value
就是一个键值对,key1
是键名,value1
是键值。非必要
锚点(anchor):是网页内部的定位点,使用#
加上锚点名称,放在网址的最后。锚点名称通过网页元素的id
属性命名。非必要
6. 为什么说HTTP协议是无状态协议?
http 是一种不保存状态,即无状态协议。http 协议自身不对请求和响应之间的通信状态进行保存。也就是说 http 协议对于发送过的请求和接受过的请求都不做持久化处理,这样可以更快地处理大量事物,确保协议的可伸缩性。
7. 怎么解决HTTP协议无状态协议? Cookie/Session
http 不保存状态,那么服务端是如何知道请求是那个客户端发送过来的呢?
Cookie状态管理 Cookie技术通过在请求和响应报文中写入Cookie信息来控制客户端的状态。 Cookie会根据从服务端发送的响应报文的一个叫Set-Cookie的首部字段,通知客户端保存Cookie。 当下次客户端再往该服务端发送请求时,客户端会自动在请求报文中加入Cookie值发送出去,服务端发现客户端发来的Cookie后,会检查是哪一个客户端发来的连接请求,对比服务器上的记录,最后得到之前的状态信息。
Session
三、应用层之HTTP请求,响应,状态码
0. HTTP报文的构成(知识点)
HTTP 报文的类型有请求报文 (Request Message) 和响应报文 (Response Message) 两种。
注:实际上还有其他类型报文,比如报文错误报文 (Error Message),空报文 (Empty Message)等,但主要以为这两种为主。
请求报文和响应报文的格式有所不同,详细见第1点和第2点。
请求报文是客户端向服务器发送的请求信息,它包含了请求方法(如 GET、POST 等)、URL、HTTP 版本号、请求头部(Request Headers)和请求主体(也称之为请求正文,Request Body)等部分。 请求报文的主要作用是向服务器请求一个页面或资源。
响应报文是服务器向客户端发送的响应信息,用于向客户端返回 HTTP 资源的状态码、消息、资源状态等信息。响应报文中包含状态码、HTTP 版本号、响应头(Response Headers)和响应正文(Response Body)等内容。 响应报文的主要作用是向客户端返回一个页面或资源的响应。
拓展(了解)
空报文 (Empty Message):空报文是一种没有任何数据的 HTTP 报文,用于服务器告诉客户端它无法处理请求或响应请求。
报文错误报文 (Error Message):报文错误报文包含错误消息和错误代码 (error code)。错误代码用于标识特定的错误情况,例如 404(Not Found) 表示请求的资源不存在,500(Server Error) 表示服务器内部错误。报文错误报文一般用于 HTTP 服务器返回错误信息时。
1. HTTP请求报文的是什么样的?
HTTP请求报文(Request Message) 由请求行 (Request Line)、请求头部 (Request Headers) 、空行和请求正文 (Request Body) 组成。 其中:
请求行 :请求行包括请求方法 (如 GET、POST 等)、URL字段(包含参数)、协议版本(如HTTP 版本号,HTTP/1.1)字段。它们⽤空格分隔。如,GET /index.html HTTP/1.1
。
请求头部:请求头部由关键字/值对组成,每⾏⼀对,关键字和值⽤英⽂冒号“:”分隔。包含请求的附加信息,如请求的 Accept 头部,用于指定可以接受的响应内容类型,或请求的 User-Agent 头部,用于标识发送请求的客户端类型。通常以字节流的形式进行传输。
User-Agent
:产⽣请求的浏览器类型。
Accept
:客户端可识别的内容类型列表。
Host
:请求的主机名,允许多个域名同处⼀个IP地址,即虚拟主机。
空行(CR+LF):空行是请求头部和请求正文之间的空行。
请求正文:包含了请求需要传输的数据。例如,在使用 POST 、PUT等方法提交数据时,请求正文中包含了提交的数据,而GET方法没有携带数据。请求正文通常以文本的形式进行传输。
2. HTTP响应报文的是什么样的?
HTTP响应报文 (Response Message) 由响应行 (Response Line)、响应头部(Response Headers)、空行和响应正文(Response Body)组成。 其中:
响应行:响应行由网络协议版本,状态码和状态值(状态码的原因短语)组成,例如 HTTP/1.1 200 OK
。
响应头部:类似请求头部,也是一系列的key-value值,包含了响应报文的元数据,如请求方法、请求头、响应状态码等。如 “Content-Type” 头部字段的属性包括 “text/html” 和 “UTF-8”。
空行:空行是响应头部和响应主体之间的空行,用于分隔响应头部和响应主体。
响应正文(响应主体):是响应报文的实际数据,通常是数据流或者文件。当请求是 GET 时,响应报文体通常是数据流;当请求是 POST 时,响应报文体通常是文件。响应主体由一系列数据块组成,每个数据块通常由一个或多个字段组成,字段之间用特定字符分隔,如 JSON 格式的响应主体由一系列对象组成,对象之间用逗号分隔。
3. 常见的HTTP首部字段?请求头和响应头?
根据前面对HTTP报文类型的介绍:
HTTP报文由HTTP首部和HTTP报文体两个部分组成。空行以上为首部字段,包含请求/响应行和请求/响应头部,空行以下为HTTP报文体。请求头和响应头一般用于描述HTTP报文的状态和设置的一些信息等。比如在连接HTTP链接时,HTTP报文通常会设置Cache-Control来指定请求和响应遵循的缓存机制,设置Connection 来管理是否长连接。在发送HTTP请求时,请求头中通常会包含Accept字段用来表示浏览器(客户端)能够处理的内容类型,用Host字段表示请求的主机名,用Cookie字段表示服务器接收到的Cookie信息;而在响应HTTP请求时,HTTP响应头中通常会包含Set-Cookie字段表示开始状态管理所使用的Cookie信息,用Content-Type 返回内容的类型让我们的浏览器判断是渲染HTML文件,还是打开资源下载,用server字段表示响应的服务器名称。
因此,请求报文和响应报文的首部主要为:
请求报文 :请求行,请求首部字段,通用首部字段,实体首部字段;
响应报文 :状态行,响应首部字段,通用首部字段,实体首部字段。
各首部字段介绍
通用首部字段(请求报文和响应报文都会使用的字段)
Connection:浏览器与服务器之间连接的类型
Session(非 HTTP 1.1 首部字段):主要用于在 HTTP 请求和响应中标识和管理系统会话,以便服务器可以正确地管理客户端的会话状态。在 HTTP 请求中,Session 首部字段通常包含会话 ID、会话状态和会话有效期等信息,以便服务器可以正确地管理客户端的会话。在 HTTP 响应中,Session 首部字段通常用于指示客户端应该创建一个新的会话,或者将客户端会话状态保存到服务器上。由于HTTP是无协议的,因此会使用Cookie来管理Session,因此Session的实现是依赖于Cookie的
Cookie 由于HTTP是无状态协议 ,即无法记住之前与其通讯的客户端;Cookie技术通过在请求和响应报文中写入Cookie信息来控制客户端的状态;
实体首部字段(针对请求报文和响应报文的实体部分使用的首部,补充了资源内容更新时间等实体有关的信息)
请求首部字段
Cookie:当前页面设置的任何Cookie
Host:发出请求的页面所在的域
Referer:发出请求的页面的
URLUser-Agent:浏览器的用户代理字符串
Accept:浏览器能够处理的内容类型
Accept-Charset:浏览器能够显示的字符集
Accept-Encoding:浏览器能够处理的压缩编码
Accept-Language:浏览器当前设置的语言
响应首部字段
server:服务器名称
content-type:表示后面的文档属于什么MIME类型
常见的 Content-Type 属性值有以下四种: (1)application/x-www-form-urlencoded:浏览器的原生 form 表单,如果不设置 enctype 属性,那么最终就会以 application/x-www-form-urlencoded 方式提交数据。该种方式提交的数据放在 body 里面,数据按照 key1=val1&key2=val2 的方式进行编码,key 和 val 都进行了 URL转码。 (2)multipart/form-data:该种方式也是一个常见的 POST 提交方式,通常表单上传文件时使用该种方式。 (3)application/json:服务器消息主体是序列化后的 JSON 字符串。 (4)text/xml:该种方式主要用来提交 XML 格式的数据。
补充
1-请求头:
2-响应头:
4. HTTP状态码
HTTP 状态码 (HTTP Status Code) 是指当用户在访问 Web 服务器时,服务器返回的响应状态码。状态码用来告知用户请求是否成功、是否出现错误以及是否需要重新请求等。
1xx:指示信息类
,表示请求已接受,继续处理(临时响应)
2xx:指示成功类
,表示请求已成功接受
3xx:指示重定向
,表示要完成请求必须进行更近一步的操作
4xx:指示客户端错误
,请求有语法错误或请求无法实现
5xx:指示服务器错误
,服务器未能实现合法的请求
常见状态码
【301】永久重定向,浏览器会把重定向后的地址缓存起来,将来用户再次访问原始地址时,直接引导用户访问新地址
【302】临时重定向,浏览器会引导用户进入新地址,但不会缓存原始地址,下一次用户访问源地址时,浏览器仍然要请求原地址的服务器
【304】表示【所请求的资源并未修改(命中协商缓存)】资源未修改,服务器通过该状态码告诉客户端,请求的资源和过去一样,并没有任何变化,建议自行使用过去的缓存。通常,304 状态码的响应中,服务器不会附带任何的响应体。
【403】表示【服务器拒绝执行客户端的请求】不允许访问。服务器通过该状态码告诉客户端,这个资源目前不允许访问。这种状态码通常出现在权限不足的情况下。
【404】表示【服务器找不到客户端所请求的资源(网页)】请求的资源不存在。请求的 url 不存在,一般是 url 出错。
其他状态码
200:成功返回响应
201:请求成功,服务器已经成功创建新的资源,并返回请求的资源。
202:请求已经被接受,但服务器正在处理请求,稍后会返回响应。
203:请求已经被接受,但服务器需要进一步确认请求是否正确,才会返回响应。
204:请求成功,服务器已经成功返回请求的资源,但没有生成新的资源。
301:永久重定向,请求的资源已经被永久移动到新的位置,并且以后所有对该资源的请求都应该使用新的位置。
302:临时重定向,请求的资源已经被临时移动到新的位置,并且以后所有对该资源的请求都应该使用新的位置。
303:请求的资源已经被重定向到另一个资源。
304:请求的资源已经被成功缓存,并且以后所有对该资源的请求都应该使用缓存。资源未修改,服务器通过该状态码告诉客户端,请求的资源和过去一样,并没有任何变化,建议自行使用过去的缓存。
307 temporary redirect,临时重定向,和302含义类似,但是期望客户端保持请求方法不变向新的地址发出请求
400:发送的请求错误,请求格式错误,或者没有服务器要求的数据。
401:没有权限访问,当前用户没有权限访问此资源。请求的认证失败,服务器无法验证请求者的身份。
403: 请求被服务器禁止。服务器已经理解请求,但是拒绝提供请求的资源。
404:请求的 url 不存在,一般是 url 出错。
500: 服务器处理请求出现错误。一些自定义的服务器可能对于所有的 5XX 类型错误都返回 500 状态码。
501:服务器超出能力之外的方法,例如:请求的方法服务器不支持。
504:来自网关或者代理服务器,请求资源服务器时超时。
状态码及其常见原因短语(状态值)
1xx
100 Continue :表明到目前为止都很正常,客户端可以继续发送请求或者忽略这个响应。
2xx
200 OK:从客户端发出的请求在服务器端被正确处理了
204 No Content :请求已经被成功处理,返回的相应报文中不含主体数据;
3xx
301 Moved Permanently :永久性重定向,为资源的请求分配了新的URI,以后都要使用这一个URI;
302 Found :临时性重定向,为资源的请求分配了新的URL,仅限于本次;
303 See Other :和 302 有着相同的功能,但明确表明需用GET方式获取资源;
304 Not Modified :如果请求报文首部包含一些条件,例如:If-Match,If-Modified-Since,If-None-Match,If-Range,If-Unmodified-Since,如果不满足条件,则服务器会返回 304 状态码
307 Temporary Redirect :临时重定向,与 302 的含义类似,但307遵守不将POST变为GET请求。
4xx
400 Bad Request :请求报文中存在语法错误,服务器无法理解;
401 Unauthorized :该状态码表示发送的请求需要有认证信息(BASIC 认证、DIGEST 认证)。如果之前已进行过一次请求,则表示用户认证失败;
403 Forbidden :对资源的访问请求被服务器拒绝了;
404 Not Found:服务器上无法找到请求的资源。
5xx
500 Internal Server Error :服务器在执行请求时发生了错误,无法提供资源;
501:表示服务器不支持请求的功能,或者无法完成请求。
503 Service Unavailable :服务器暂时处于超负载或正在进行停机维护,现在无法处理请求。 使用场景:
服务器停机维护时,主动用503响应请求;
nginx 设置限速,超过限速,会返回503。
504 Gateway Timeout: 使用场景:代码执行时间超时,或者发生了死循环。
5. HTTP状态码304【是多好还是少好】
首先,304状态码表示请求的资源已经被成功缓存,并且以后所有对该资源的请求都应该使用缓存,是对客户端有缓存情况下的服务器的一种响应。当服务器为提高网站访问速度,会对之前访问的部分页面指定缓存机制,当客户端在此对这些页面进行请求,服务器会根据缓存内容判断页面与之前是否相同,若相同便直接返回304,此时客户端调用缓存读取页面资源,而不是从原始服务器读取资源。所以,HTTP 304状态码通常用于缓存图片等静态资源。
虽然上面的例子可以看出,304状态码可以提高网站访问速度,减少服务器的负担,但它同时也占用了客户端的一部分内存,也可能导致页面回访率下降,收录减少,权重下降等问题。比如网站如果长期处于304状态(页面长期不更新/更新周期长),则搜索引擎可能会降低对它的抓取,这可能导致网站快照停止。因此,状态码304的使用次数好坏取决于具体的应用场景。
6. 同样是重定向,301,302,303和307之间的区别?
首先,301是永久重定向,而302,303和307是临时重定向,其中303和307是在HTTP 1.1版本后从302状态码衍生出来的。
对于永久重定向和临时重定向的区别,主要在于浏览器会不会缓存重定向的地址,网页是不是已经永久地移动到新的位置,如果是永久缓存则浏览器会缓存重定向地址,网页会永久的移动到新的位置,否则相反。因此,301更加适合地址永久转移的场景,比如域名变更;而 302 适合临时转移的场景,比如首页临时跳转到活动页。
对于302,303和307的区别主要在于请求方法,比如303明确表示客户端应当采用GET法获取资源,他会把POST请求变为GET请求进行重定向。 307会遵照浏览器标准,要求客户端保持请求方法不变,向新的地址发出请求,不会从POST变为GET。302为资源的请求分配了新的URL,仅限于本次临时访问,主要用于GET请求、HEAD和PUT请求。
四、应用层之HTTP请求方法
0. 各种请求的简单介绍(知识点,非考题)
安全与非安全
安全的 HTTP 方法(不会改变服务器状态,为只读):GET、HEAD、OPTIONS;
非安全:POST、 PUT、DELETE。
幂等与非幂等 所有的请求实际上都可以是幂等或者非幂等,具体情况具体分析。下面的分类仅是通常情况下:
幂等(同一个请求被执行一次或多次的结果都是一致的,不会重复执行或产生副作用):GET,HEAD,PUT 和 DELETE
非幂等:POST
可缓存与不可缓存
可缓存:GET 和 HEAD
不可缓存:PUT 和 DELETE
POST:多数情况下不可缓存
1. HTTP请求方法有哪些
GET: 向服务器获取数据;
POST:将实体提交到指定的资源,通常会造成服务器资源的修改;
PUT:上传文件,更新数据;DELETE:删除服务器上的对象;
HEAD:获取报文首部,与GET相比,不返回报文主体部分;
OPTIONS:询问支持的请求方法,用来跨域请求;
CONNECT:要求在与代理服务器通信时建立隧道,使用隧道进行TCP通信;
TRACE: 回显服务器收到的请求,主要⽤于测试或诊断。
2. POST和GET有哪些区别?各自应用场景?
从HTTP协议角度上来看,GET和POS都是发送请求的方法,除了语义上的不同,其实并没有本质上的区别(本质上都是TCP链接),只不过在实际开发中受浏览器默认行为等因素的影响,他们作用的界定和适配会有所不同。主要的区别可以从四个角度来看:
第一点,从定义及作用上来看,GET 方法请求一个指定资源的表示形式,一般用于信息获取和查询。而POST方法用于将实体提交到指定的资源,通常导致在服务器上的状态变化或副作用,因此一般用来更新服务器上的资源。也就是GET不会改变服务器上的资源,是幂等的,为只读操作;而POST会对服务器资源进行改变,不是幂等的,为写操作。
第二点,从参数的角度上看,GET 请求使用URL传递参数,也就是说GET 请求的数据会放置在 HTTP 报文的请求头 (附在 URL 之后)中。由于浏览器本身对URL长度有所限制,所以GET请求传送的参数也会有长度限制(适合传递少量数据),并且由于GET请求参数暴露在URL中(不能用于传递敏感信息) ,请求的URL会被保留在历史记录中,所以GET 请求相对不太安全。与GET不同,POST 请求则会把提交的数据则放置在是 HTTP 请求报文的 请求体(Request body)中,相对安全(可以通过抓包工具查看),对所传送的信息 没有长度限制(适合传输大量数据),无需使用URL进行编码(适合铭感数据传输),可以支持多种编码方式 。对参数的数据类型,GET只接受ASCII字符,而POST没有限制。
第三点,从改变变量的方式来看,GET 方式需要使用 Request.QueryString 来取得变量的值,而 POST 方式通过 Request.Form 来获取变量的值,也就是说 Get 是通过地址栏来传值,而 Post 是通过提交表单来传值。
第四点,从浏览器表现来看,浏览器一般会主动缓存GET请求地址,而POST不会,除非手动设置。GET在浏览器回退(也就是页面刷新)时是无害的,而POST会再次提交请求。
备注:Get 请求的报文中实体部分为空,Post 请求的报文中实体部分一般为向服务器发送的数据。在使用 XMLHttpRequest方法时也有所区别,GET 只是一次 HTTP 请求,POST 先发请求头再发请求体,实际上是两次请求。但这主要时浏览器的区别,并不是所有浏览器会这么做,例如火狐就不会。post方法有时会发送两个 tcp 数据包,与浏览器有关。
注意:POST 请求可以是幂等的,也可以是不幂等的。
3. POST和PUT请求的区别
从HTTP协议角度上来看,POST 和 PUT 都是用于提交数据给服务器常用的请求方法,两者主要区别在于它们的作用和提交数据的方式。
首先,从数据提交方式来看,POST 请求将数据打包成请求体提交给服务器,请求体中的数据是可选的,并且服务器在接收到请求后会处理请求体中的数据。而 PUT 请求将数据作为请求正文提交给服务器,请求正文中的数据是必需的,并且服务器在接收到请求后会替换目标服务器上的现有数据。
其次,从作用上来看,PUT请求是利用数据修改服务器数据的内容,但不会增加数据的种类,也就是更新数据;而POST请求会改变数据的种类等资源,会创建新的内容。因此,POST 请求通常用于提交表单数据、上传文件等创建数据类型的任务 ,而 PUT 请求通常用于提交需要更新或替换的数据。
最后,从信息交互来看,PUT 请求需要确认目标服务器上的数据是否已更新,因为 PUT 请求会替换目标服务器上的现有数据。而 POST 请求不需要进行此确认,因为 POST 请求只是将数据提交给服务器,并期望服务器在接受数据后做出相应的操作。
4. GET方法URL长度限制的原因
GET请求方法会将请求数据附在URL之后,虽然HTTP协议并没有对GET方法中请求的URL的长度进行限制,但是浏览器及服务器对GET方法URL的长度有所限制。所以,GET方法的URL会有长度限制。因此,GET长度=URL长度 - (域名+路径长度)-2(这个2是get请求中?=两个字符的长度
)。由于IE浏览器对URL长度的允许值是最小的,因此在开发中,只需要满足URL不超过2083字节,那么在所有浏览器中工作都不会有问题。
5. GET请求中URL编码的意义
在GET请求中会对URL中非西文字符和参数进行编码,这样做的出了可以避免非ASCII码带来的歧义,还可以避免在传输过程中被篡改或泄露。通过采用 URL 编码,可以将 URL 中的非 ASCII 字符转换为 ASCII 字符,从而防止恶意用户对 URL 进行篡改或伪造。此外,URL 编码还可以帮助用户识别 URL 的所有权,从而避免 URL 被恶意用户篡改后造成的安全问题。
6. POST请求什么时候是两次什么时候是一次
一般情况下,POST 请求不会发送两次请求。如果出现了需要发送两次请求的情况,可能是由于客户端和服务器之间的通信协议或数据传输过程中出现的错误导致的。
POST 请求将数据附加到 URL 请求体中,用于向服务器提交数据。当服务器接收到请求时,它会将数据进行处理,然后返回一个响应。这个响应可能会包含一个状态码,用于指示请求是否成功或失败。
如果 POST 请求失败,浏览器可能会再次发送一个请求以获取更多信息或重新尝试请求。这个第二次发送的请求通常是 GET 请求,因为它不需要向服务器提交数据。
在某些情况下,可能会出现 POST 请求发送两次的情况,例如当浏览器缓存 POST 请求的数据时。在这种情况下,浏览器可能会发送两个 POST 请求,其中一个是清除缓存的请求,另一个是发送实际请求的请求。这可能会导致一些困惑和误解,因为它违反了通常的请求流程。
7. POST 请求什么时候用 form data 什么时候用 request payload
form data 适合传递简单的键值对信息,由于传递的信息比较扁平,难以传递深层次嵌套的数据
request payload 适合传递任意格式的数据,包括单个数字、布尔、深层次嵌套的对象、数组等,但 request payload 不适合传递文件数据
在前后端分离的项目中,对于非文件数据的传递,都推荐使用 request payload 的形式,以传递最明确的数据类型和数据结构,而对于文件上传,则推荐使用传统的 form data
8. OPTIONS请求方法及使用场景
OPTIONS(响应不能缓存)方法主要功能为获取服务器支持的所有请求方法和检查访问权限,因此也常用于跨域请求。在进行跨域资源共享时,可以使用OPTIONS 方法发送请求,以判断是否有对指定资源的访问权限。
下一章笔记
下一章笔记的链接: 【计算机网络】八股文 | 第二章 笔记链接:待更新 主要知识点:待更新