计算机网络面试题-（较详细整理版）
计算机网络
计算机网络体系结构
计算机网络的体系结构
应用层
应用层是为了特定的应用程序提供数据传输服务。 关键词：特定，应用程序。例如为万维网需要遵循HTTP协议，文件传输需要遵循FTP协议，域名解析服务遵循DNS协议。
协议规定了数据的请求格式、返回格式、序列化方式、长度大小等信息，使得通信的客服端和服务端能够识别具体的信息内容。
应用层用来规定应用进程在通信时所遵循的协议，应用层的许多协议都是基于客户服务器方式。客户 (client) 和服务器 (server) 都是指通信中所涉及的两个应用进程。客户服务器方式所描述的是进程之间服务和被服务的关系。客户是服务请求方，服务器是服务提供方。数据单位：报文。
涉及到的协议：
域名系统 DNS：将域名和 IP 地址相互映射的一个分布式数据库，能够使人更方便的访问互联网，而不用去记住能够被机器直接读取的 IP 数串。
HTTP协议：超文本传输协议，所有的万维网文件都必须遵守这个标准。设计 HTTP 最初的目的是为了提供一种发布和接收 HTML 页面的方法。
邮件传输协议：SMTP
运输层
运输层是为端到端的进程提供通用的数据传输服务 ，关键词：通用，端到端。这一层这是传输无格式的字节流，服务器如果要理解具体信息内容，需要靠应用层，这里重点是保证字节数据能够传输到对端即可。
只有位于网络边缘部分的主机的协议栈才有运输层，和网络层不同，网络层是为主机之间提供逻辑通信，而运输层为应用进程之间提供通用的数据传输服务（端到端的服务）。运输层拥有流量控制（防止过载，即过多的数据注入到网络中），拥塞控制（抑制数据传输的速率）等功能，为上层协议提供端到端的可靠和透明的数据传输服务,上层服务用户不必关系通信子网的实现细节。
运输层主要使用以下两种协议：
传输控制协议 TCP：面向连接的协议，提供可靠的数据传输服务。数据单位为：报文段
用户数据报协议 UDP：无连接的协议，不提供可靠交付。数据单位：用户数据报
运行在TCP协议上的协议：
HTTP（Hypertext Transfer Protocol，超文本传输协议）Web服务器传输超文本到本地浏览器的传送协议。端口：80
HTTPS（HTTP over SSL，安全超文本传输协议）,HTTP协议的安全版本。端口： 443
FTP（File Transfer Protocol，文件传输协议），用于文件传输。端口：21
SMTP（Simple Mail TransferProtocol，简单邮件传输协议），用来发送电子邮件。端口：25
SSH（SecureShell，用于替代安全性差的TELNET），用于加密安全登陆用。端口：22
运行在UDP协议上的协议：
DNS（Domain Name Service，域名服务），用于完成地址查找，邮件转发等工作。
SNMP（Simple Network Management Protocol，简单网络管理协议），用于网络信息的收集和网络管理。
NTP（Network Time Protocol，网络时间协议），用于网络同步。
DHCP（Dynamic Host Configuration Protocol，动态主机配置协议），动态配置IP地址。
网络层
主机节点之间连接，通俗就是两台电脑之间。
网络层采用了IP数据报服务：通过IP寻址来建立两个节点之间的连接，之后把运输层产生的报文段或用户数据报封装成分组和包进行传送，在发送分组时不需要先建立连接，每一个分组独立发送，与其前后的分组无关。在这个过程中网络层不提供端到端的可靠传输服务，尽最大努力进行交付（由网络的主机中的运输层负责可靠交付）。
网际协议 IP 是 TCP/IP 体系中两个最主要的协议之一，与 IP 协议配套使用的还有三个协议：
- 地址解析协议 ARP (Address Resolution Protocol)
- 网际控制报文协议 ICMP (Internet Control Message Protocol)
- 网际组管理协议 IGMP (Internet Group Management Protocol)
ARP（Address Resolution Protocol，地址解析协议），ARP协议完成了IP地址与物理地址的映射，用于动态解析以太网硬件的地址
工作原理：
- 首先，每台主机都会在自己的ARP缓冲区中建立一个ARP列表，以表示IP地址和MAC地址的对应关系。
- 当源主机需要将一个数据包要发送到目的主机时，会首先检查自己ARP列表中是否存在该IP地址对应的MAC地址：
- 如果有，就直接将数据包发送到这个MAC地址；
- 如果没有，就向本地网段发起一个ARP请求的广播包，查询此目的主机对应的MAC地址。此ARP请求数据包里包括源主机的IP地址、硬件地址、以及目的主机的IP地址。
- 网络中所有的主机收到这个ARP请求后，会检查数据包中的目的IP是否和自己的IP地址一致。
- 如果不相同就忽略此数据包；如果相同，该主机首先将发送端的MAC地址和IP地址添加到自己的ARP列表中，
- 如果ARP表中已经存在该IP的信息，则将其覆盖，然后给源主机发送一个ARP响应数据包，告诉对方自己是它需要查找的MAC地址；
- 源主机收到这个ARP响应数据包后，将得到的目的主机的IP地址和MAC地址添加到自己的ARP列表中，并利用此信息开始数据的传输。
- 如果源主机一直没有收到ARP响应数据包，表示ARP查询失败。
数据链路层
数据链路层：两台设备之间的数据传输，可以看成是在一条管道上进行的，传送的数据单位是帧（每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）），链路层保证被传输数据的正确性。
三个问题：
- 封装成帧 ：就是在一段数据的前后分别添加首部和尾部，然后就构成了一个帧，首部和尾部的一个重要作用就是进行帧定界。
- 透明传输：在数据传输过程中，如果数据中的某个字节的二进制代码恰好和 SOH 或 EOT 一样，数据链路层就会错误地“找到帧的边界”从而导致这些数据都能够按照原样没有差错地通过这个数据链路层。解决透明传输问题：字符填充 (插入转义字符)
- 差错检测：在传输过程中可能会产生比特差错：1 可能会变成 0， 而 0 也可能变成 1。在一段时间内，传输错误的比特占所传输比特总数的比率称为误码率 BER (Bit Error Rate)，误码率与信噪比有很大的关系，为了保证数据传输的可靠性，在计算机网络传输数据时，必须采用各种差错检测措施，在数据链路层传送的帧中，广泛使用了循环冗余检验 CRC 的检错技术。
物理层
物理层考虑的是怎样才能在连接各种计算机的传输媒体上传输数据比特流，它的作用是要尽可能地屏蔽掉不同传输媒体和通信手段的差异。使上层的数据链路层不必考虑网络的具体传输介质是什么。传输的是比特
物理层的主要任务：确定与传输媒体的接口的一些特性（器件的相关特性，电压范围，以及对应的功能）
网络协议分层的好处？
- 简化问题难度和复杂度。由于各层之间独立，我们可以分割大问题为小问题。
- 灵活性好。当其中一层的技术变化时，只要层间接口关系保持不变，其他层不受影响。
- 易于实现和维护。
- 促进标准化工作。分开后，每层功能可以相对简单地被描述
TCP与UDP
- TCP/IP即传输控制协议，是面向连接的协议，发送数据前要先建立连接，TCP提供可靠的服务，也就是说，通过TCP连接传输的数据不会丢失，没有重复，并且按顺序到达。（类似于打电话）
- UDP它是属于TCP/IP协议族中的一种。是无连接的协议，发送数据前不需要建立连接，是没有可靠性的协议。因为不需要建立连接所以可以在在网络上以任何可能的路径传输，因此能否到达目的地，到达目的地的时间以及内容的正确性都是不能被保证的。（类似于发微信）
TCP的三次握手
在网络数据传输中，传输层协议TCP是要建立连接的可靠传输，TCP建立连接的过程，我们称为三次握手。
三次握手的具体细节：客户端向服务端发送SYN -> 服务端返回SYN,ACK -> 客户端发送ACK
图中主机B的TCP 服务器进程先创建传输控制块TCB，准备接受客户进程的连接请求。
- 第一次握手：主机A 的 TCP 向 主机B 发出连接请求报文段，其首部中的同步位 SYN = 1，并选择序号 seq = x，表明传送数据时的第一个数据字节的序号是 x。
- 第二次握手：主机B 的 TCP 收到连接请求报文段后，如同意，则发回确认。主机B 在确认报文段中应使 SYN = 1，使 ACK = 1，其确认号 ack = x + 1，自己选择的序号 seq = y。
- 第三次握手：主机A 收到此报文段后向 主机B 给出确认，其 ACK = 1，确认号 ack = y + 1。主机A 的 TCP 通知上层应用进程，连接已经建立。主机B 的 TCP 收到主机 A 的确认后，也通知其上层应用进程：TCP 连接已经建立。
三次握手的目的是建立可靠的通信信道，主要的目的就是双方确认自己与对方的发送与接收都正常。
- 第一次握手：客户什么都不能确认；服务器确认了对方发送正常
- 第二次握手：客户确认了：自己发送、接收正常，对方发送、接收正常；服务器确认了：自己接收正常，对方发送正常
- 第三次握手：客户确认了：自己发送、接收正常，对方发送、接收正常；服务器确认了：自己发送、接收正常，对方发送、接收正常 所以三次握手就能确认双发收发功能都正常，缺一不可。
如果已经建立了连接，但客户端出现了故障怎么办？
保活计时器：用来防止在TCP连接出现长时期的空闲。服务器每收到一次客户端的请求后都会重新复位一个计时器，时间通常是设置为2小时，若服务器过了2小时还没有收到客户的信息，它就发送探测报文段。若发送了10个探测报文段（每一个相隔75秒）还没有响应，就假定客户出了故障，因而就终止该连接。
为什么三次握手？而不是两次或四次？
说法一：为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误
说法二：为了解决“网络中存在延迟的重复分组”的问题
已失效的连接请求报文段” 的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。如果四次，那么就造成了浪费，因为在三次结束之后，就已经可以保证A可以给B发信息，A可以收到B的信息； B可以给A发信息，B可以收到A的信息。
什么是TCP的四次挥手？
数据传输结束后，通信的双方都可释放连接，我们将释放连接的过程我们称为四次挥手：
四次挥手的具体细节
- 第一次挥手：主机A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP 连接。主机A 把连接释放报文段首部的FIN = 1，其序号seq = u，等待 B 的确认（FIN_WAIT_1状态）。
- 第二次挥手：主机B 发出确认，发送一个ACK=1，确认号 ack = u+1，而这个报文段自己的序号 seq = v。TCP 服务器进程通知高层应用进程。从主机A 到主机B 这个方向的连接就释放了，TCP 连接处于CLOSE_WAIT状态。此时主机B 若发送数据，主机A 仍要接收。
- 第三次挥手：主机B 确认已经没有要向主机A 发送的数据，将FIN置1，其应用进程就通知 TCP 释放连接。
- 第四次挥手：主机A 收到连接释放报文段后，进入TIME_WAIT状态，必须发出确认。 在确认报文段中ACK = 1，确认号 ack = w + 1，自己的序号 seq = u + 1。主机B收到后，确认ack后，变为CLOSED状态，不再向客户端发送数据。客户端等待2*MSL（报文段最长寿命）时间后，也进入CLOSED状态。完成四次挥手。
简单理解：四次挥手，双方都确认对方关闭
- 客户对服务器发送了关闭连接请求，
- 服务器收到客户的关闭连接请求后，回复一个确认收到的消息
- 服务器确定不再给客户发消息后，对客户发送，准备关闭连接的消息
- 客户收到服务器要关闭连接的消息给服务器发送：已收到关闭连接的消息。
为什么不能把服务器发送的ACK和FIN合并起来，变成三次挥手（CLOSE_WAIT状态意义是什么）？
因为服务器收到客户端断开连接的请求时，可能还有一些数据没有发完，这时先回复ACK，表示接收到了断开连接的请求。等到数据发完之后再发FIN，断开服务器到客户端的数据传送。
如果第二次挥手时服务器的ACK没有送达客户端，会怎样？
客户端没有收到ACK确认，会重新发送FIN请求。
客户端TIME_WAIT状态的意义是什么？
两个问题：
- 主机A 发送的最后一个 ACK 报文段可能没有到达主机B（丢失）、
- 已失效的连接请求报文段可能出现在本连接中
TIME_WAIT状态用来重发可能丢失的ACK报文。如果服务端没有收到ACK，就会重发FIN，如果客户端在2*MSL的时间内收到了FIN，就会重新发送ACK并再次等待2MSL，防止Server没有收到ACK而不断重发FIN。
MSL(MaximumSegment Lifetime)，指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。
TCP 协议如何保证可靠传输？
- 停止等待：每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
- 超时重传：当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
- 流量控制：TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP使用的流量控制协议是可变大小的滑动窗口协议。
- 拥塞控制： 当网络拥塞时，可能会造成网络的拥堵，甚至网络瘫痪，TCP会减少数据的发送。
- 数据包校验：TCP 将保持它首部和数据的检验和，这是一个端到端的检验和。目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时TCP发送数据端超时后会重发数据；
- 对失序数据包重排序：既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。TCP给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
- 应答机制：当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒；
- 丢弃重复数据：TCP 的接收端会丢弃重复的数据。
TCP拥塞控制？
拥塞控制是防止过多的数据注入网络，使得网络中的路由器或者链路过载。流量控制是点对点的通信量控制，而拥塞控制是全局的网络流量整体性的控制。发送双方都有一个拥塞窗口（cwnd）。
- 慢开始：最开始发送方的拥塞窗口为1，由小到大递增。每经过一个传输轮次，拥塞窗口cwnd加倍（乘2）。当cwnd超过慢开始门限，则使用拥塞避免算法，避免cwnd增长过长。
- 拥塞避免（算法）：当cwnd超过慢开始门限，每经过一个往返时间RTT，cwnd就增长1。在慢开始和拥塞避免过程中，一旦发现网络拥塞，就把慢开始门限设置为当前值的一半，并且重新设置cwnd为1，重新慢启动。
- 快重传：接收方每收到一个失序的报文段后就立即发出重复确认，发送方只要收到3个重复确认就立即重传，而不必继续等待设置的重传计时器时间到期。
- 快恢复：当发送方连续收到三个重复确认，就将慢开始门限减半，将当前的窗口设置为慢开始门限，并采用拥塞避免算法。（采用快恢复算法时，慢开始只在建立连接和网络超时时才使用）
什么是Http协议？
HTTP是一个基于TCP/IP通信协议来传递数据的协议。HTTP协议工作于客户端-服务端架构之上，实现可靠性的传输文字、图片、音频、视频等超文本数据的规范，格式简称为“超文本传输协议”。Http协议属于应用层，用户访问的第一层就是http。
特点：
- ①简单快速：客户端向服务器发送请求时，只需传送请求方法和路径即可。
- ②灵活：HTTP允许传输任意类型的数据对象。
- ③无连接：限制每次连接只处理一个请求。服务器处理完客户请求，并收到客户应答后，即断开连接。
- ④无状态：协议对于事务处理没有记忆能力。
- ⑤支持B/S及C/S模式。
Http和Https的区别？
- 端口不同：Http是80，Https443
- 安全性：http是超文本传输协议，信息是明文传输，https则是通过SSL加密处理的传输协议，更加安全。
- 是否付费：https需要拿到CA证书，需要付费
- 连接方式：http和https使用的是完全不同的连接方式（HTTP的连接很简单，是无状态的；HTTPS 协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。）
HTTPS传输过程中使用密钥加密，安全性更高。但是收费，而且多了一层SSL延时也会有所提高。
HTTPS工作原理
- 首先HTTP请求服务端生成证书，客户端对证书的有效期、合法性、域名是否与请求的域名一致、证书的公钥（RSA加密）等进行校验；
- 建立会话密钥，RSA公钥加密：客户端如果校验通过后，就根据证书的公钥的有效， 生成随机数，随机数使用RSA公钥进行加密（RSA加密）；
- 消息体产生的后，对它的摘要进行MD5（或者SHA1）算法加密，此时就得到了RSA签名；
- RSA私钥解密：发送给服务端，此时只有服务端（RSA私钥）能解密。
- 解密得到的随机数，再用AES加密，作为密钥（此时的密钥只有客户端和服务端知道）。
- web服务器利用会话密钥加密与客户端之间的通信。
HTTPS采用混合的加密机制，使用非对称密钥加密用户传输对称密钥来保证传输过程的安全性，之后使用对称密钥加密进行通信来保证通信过程的效率。
加密算法
加密算法：对信息进行编码和解码的技术，编码是把原来可读信息（又称明文）译成代码形式（又称密文），其逆过程就是解码（解密）。
加密技术的要点是加密算法，加密算法可以分为三类：
对称加密，如 AES
基本原理：将明文分成 N 个组，然后使用密钥对各个组进行加密，形成各自的密文，最后把所有的分组密文进行合并，形成最终的密文。
优点：算法公开、计算量小、加密速度快、加密效率高
缺点：双方都使用同样密钥，安全性得不到保证
非对称加密，如 RSA
基本原理：同时生成两把密钥：私钥和公钥，私钥隐秘保存，公钥可以下发给信任客户端
私钥加密，持有私钥或公钥才可以解密
公钥加密，持有私钥才可解密
优点：安全，难以破解
缺点：算法比较耗时
不可逆加密，如 MD5，SHA
基本原理：加密过程中不需要使用密钥，输入明文后由系统直接经过加密算法处理成密文，这种加密后的数据是无法被解密的，无法根据密文推算出明文。
对称加密的特点：对称密码体制中只有一种密钥，并且是非公开的。如果要解密就得让对方知道密钥，所以想要保证其安全性就要保证密钥的安全。
非对称加密的特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，而使得加密解密速度没有对称加密解密的速度快。非对称密钥体制有两种密钥，其中一个是公开的，这样就可以不需要像对称密码那样传输对方的密钥了，这样安全性就大了很多。
非对称加密公钥和私钥的使用方法：(1) 公钥加密私钥解密。(2) 私钥做数字签名，公钥验证。
一次完整的HTTP请求所经历几个步骤?
HTTP协议采用请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应内容包括协议版本、成功或者错误的代码、服务器信息、响应头部和响应数据。
Web浏览器与Web服务器之间将完成下列7个步骤：
- 建立TCP连接，三次握手
- Web浏览器向Web服务器发送请求行
- Web浏览器发送请求头：浏览器发送其请求命令之后，还要以头信息的形式向Web服务器发送一些别的信息，之后浏览器发送了一空白行来通知服务器，它已经结束了该头信息的发送。
- Web服务器**应答：**客户机向服务器发出请求后，服务器会客户机回送应答， HTTP/1.1 200 OK ，应答的第一部分是协议的版本号和应答状态码。
- Web服务器发送应答头：正如客户端会随同请求发送关于自身的信息一样，服务器也会随同应答向用户发送关于它自己的数据及被请求的文档。
- Web服务器向浏览器发送数据：Web服务器向浏览器发送头信息后，它会发送一个空白行来表示头信息的发送到此为结束，接着，它就以Content-Type应答头信息所描述的格式发送用户所请求的实际数据。
- Web服务器关闭TCP连接
什么是http的请求体？
HTTP请求体是我们请求数据时先发送给服务器的数据，毕竟我向服务器拿数据，先要表明我要什么吧，HTTP请求体由：请求行 、请求头、请求数据组成的，
http的响应报文有哪些？
http的响应报是服务器返回给我们的数据，必须先有请求体再有响应报文.响应报文包含三部分： 状态行、响应首部字段、响应内容实体实现
输入网址到获取页面的过程？
- 浏览器搜索自身的DNS缓存、搜索操作系统的DNS缓存、读取本地的Host文件和向本地DNS服务器进行查询等。
- 对于向本地DNS服务器进行查询，如果要查询的域名包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析(此解析具有权威性)；如果要查询的域名不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析（此解析不具有权威性）。如果本地域名服务器并未缓存该网址映射关系，那么将根据其设置发起递归查询或者迭代查询；
- 浏览器获得域名对应的IP地址以后，浏览器向服务器请求建立链接，发起三次握手；
- TCP/IP链接建立起来后，浏览器向服务器发送HTTP请求；
- 服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器；
- 浏览器解析并渲染视图，若遇到对js文件、css文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；
- 浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面
http版本的对比
HTTP1.0版本的特性：
早先1.0的HTTP版本，是一种无状态、无连接的应用层协议。（短连接）
HTTP1.0规定浏览器和服务器保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器处理完成后立即断开TCP连接（无连接），服务器不跟踪每个客户端也不记录过去的请求（无状态）。
HTTP1.1版本新特性（长连接）：
默认持久连接节省通信量，只要客户端服务端任意一端没有明确提出断开TCP连接，就一直保持连接，可以发送多次HTTP请求管线化，客户端可以同时发出多个HTTP请求，而不用一个个等待响应断点续传原理
HTTP2.0版本的特性：
- 二进制分帧（采用二进制格式的编码将其封装）
- 首部压缩（设置了专门的首部压缩设计的HPACK算法。）
- 流量控制（设置了接收某个数据流的多少字节一些流量控制）
- 多路复用（可以在共享TCP链接的基础上同时发送请求和响应）
- 请求优先级（可以通过优化这些帧的交错和传输顺序进一步优化性能）
- 服务器推送（就是服务器可以对一个客户端请求发送多个响应。服务器向客户端推送资源无需客户端明确的请求。（重大更新））
HTTP长连接和短连接
常用HTTP状态码是怎么分类的，有哪些常见的状态码？
HTTP状态码表示客户端HTTP请求的返回结果、标识服务器处理是否正常、表明请求出现的错误等。状态码的类别：
常用状态码：
200： 请求被正常处理
204： 请求被受理但没有资源可以返回
301： 永久性重定向
302： 临时重定向
304： 已缓存
400： 请求报文语法有误，服务器无法识别
403： 请求的对应资源禁止被访问
404： 服务器无法找到对应资源
500： 服务器内部错误
503： 服务器正忙
HTTP协议中的请求方式
客户端发送的 请求报文 第一行为请求行，包含了方法字段。
根据 HTTP 标准，HTTP 请求可以使用多种请求方法。
HTTP1.0 定义了三种请求方法： GET, POST 和 HEAD方法。
HTTP1.1 新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。
| 序 号 | 方法 | 描述 |
|---|---|---|
| 1 | GET | 请求指定的页面信息，并返回实体主体。 |
| 2 | HEAD | 类似于 GET 请求，只不过返回的响应中没有具体的内容，用于获取报头 |
| 3 | POST | 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。 |
| 4 | PUT | 从客户端向服务器传送的数据取代指定的文档的内容。 |
| 5 | DELETE | 请求服务器删除指定的页面。 |
| 6 | CONNECT | HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。 |
| 7 | OPTIONS | 允许客户端查看服务器的性能。 |
| 8 | TRACE | 回显服务器收到的请求，主要用于测试或诊断。 |
| 9 | PATCH | 是对 PUT 方法的补充，用来对已知资源进行局部更新 。 |
GET方法与POST方法的区别
-
get是获取数据，post是修改数据
-
get把请求的数据放在url上， 以?分割URL和传输数据，参数之间以&相连，所以get不太安全。而post把数据放在HTTP的包体内（requrest body）
-
get提交的数据最大是2k（ 限制实际上取决于浏览器）， post理论上没有限制。
-
GET产生一个TCP数据包，浏览器会把http header和data一并发送出去，服务器响应200(返回数据); POST产生两个TCP数据包，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok(返回数据)。
-
GET请求会被浏览器主动缓存，而POST不会，除非手动设置。
-
本质区别：GET是幂等的，而POST不是幂等的
这里的幂等性：幂等性是指一次和多次请求某一个资源应该具有同样的副作用。简单来说意味着对同一URL的多个请求应该返回同样的结果。
正因为它们有这样的区别，所以不应该且不能用get请求做数据的增删改这些有副作用的操作。因为get请求是幂等的，在网络不好的隧道中会尝试重试。如果用get请求增数据，会有重复操作的风险，而这种重复操作可能会导致副作用（浏览器和操作系统并不知道你会用get请求去做增操作）
Session 与 Cookie 的对比
cookie：cookie是由Web服务器保存在用户浏览器上的文件（key-value格式），可以包含用户相关的信息。客户端向服务器发起请求时，会携带服务器端之前创建的cookie，服务器端通过cookie中携带的数据区分不同的用户。
session：session 是浏览器和服务器会话过程中，服务器会分配的一块储存空间给session。服务器默认会为客户浏览器的cookie中设置 sessionid，这个sessionid就和cookie对应，浏览器在向服务器请求过程中传输的cookie 包含 sessionid ，服务器根据传输cookie 中的 sessionid 获取出会话中存储的信息，然后确定会话的身份信息。
- 安全性：cookie数据存放在客户端上，安全性较差，session数据放在服务器上，安全性相对更高
- 大小限制：cookie有大小限制，单个cookie保存的数据不能超过4K，session无此限制，理论上只与服务器的内存大小有关；
- 服务器资源消耗：Session是保存在服务器端上会存在一段时间才会消失，当访问增多，对服务器性能有影响
- 实现机制：Session的实现常常依赖于Cookie机制，通过Cookie机制回传SessionID；
HTTP协议本身是无法判断用户身份。所以需要cookie或者session
参考资料
-
计算机网络面试题（超详细整理）
-
TCP的拥塞控制（详解）
-
阿秀求职笔记