《2021春招复习11》计算机网络《计算机网络》

1、计算机网路的分层：

不同的协议栈用于定义和管理不同网络的数据转发规则。

分层模型- OSI

国际标准化组织ISO于1984年提出了OSI RM（Open System Interconnection Reference Model，开放系统互连参考模型）。OSI 参考模型很快成为了计算机网络通信的基础模型。

OSI参考模型具有以下优点：

1、简化了相关的网络操作；
2、提供了不同厂商之间的兼容性；
3、促进了标准化工作；
4、结构上进行了分层；
5、易于学习和操作。

OSI参考模型各个层次的基本功能如下：

1、物理层: 在设备之间传输比特流，规定了电平、速度和电缆针脚。

2、数据链路层：将比特组合成字节，再将字节组合成帧，使用链路层地址（以太网使用MAC地址）来访问介质，并进行差错检测。

3、网络层：提供逻辑地址，供路由器确定路径。

4、传输层：提供面向连接或非面向连接的数据传递以及进行重传前的差错检测。

5、会话层：负责建立、管理和终止表示层实体之间的通信会话（打印机等设备）。该层的通信由不同设备中的应用程序之间的服务请求和响应组成。

6、表示层：提供各种用于应用层数据的编码和转换功能（加密解密），确保一个系统的应用层发送的数据能被另一个系统的应用层识别。

7、应用层：OSI参考模型中最靠近用户的一层，为应用程序提供网络服务。

分层模型– TCP/IP

1、TCP/IP模型同样采用了分层结构，层与层相对独立但是相互之间也具备非常密切的协作关系。

2、TCP/IP模型将网络分为四层。TCP/IP模型不关注底层物理介质，主要关注终端之间的逻辑数据流转发。

3、TCP/IP模型的核心是网络层和传输层：网络层解决网络之间的逻辑转发问题，传输层保证源端到目的端之间的可靠传输。最上层的应用层通过各种协议向终端用户提供业务应用。

应用层：

为特定应用程序提供数据传输服务，例如Http，DNS等协议，数据单位为报文。

传输层：

为进程提供通用数据传输服务。由于应用层协议很多，定义通用的传输层协议就可以支持不断增多的应用层协议。运输层包括两种协议：TCP和UDP。TCP（完整性服务）：提供面向连接、可靠的数据传输服务，数据单位是报文段，UDP（及时性服务）：提供无连接诶的，尽最大努力的数据传输服务，数据单位用户数据报。

网络层：

IP地址

网络接口层：

MAC地址

集线器工作在物理层，交换机工作在数据链路层，路由器工作在网络层(IP)。

2、TCP和UDP区别

用户数据报协议UDP(User　Datagram Protocol)是无连接的，尽最大可能交付，没有拥塞控制，面向报文（对于应用程序传下来的报文不合并也不拆分，只是添加UDP的首部），支持一对一，一对多，多对一和多对多的交互通信。

传输控制协议TCP(Transmission Control Protocol)是面向连接的，提供可靠交付，有流量控制，拥塞控制，提供全双工通信，面向字节流（把应用层传下来的报文看成字节流，把字节流组织成大小不等的数据块），每一条TCP连接只能是点对点的(一对一)。（其中TCP的结构包括什么？源目的地址，序列号，确认序列号，窗口大小，校验和，数据）

所以如果我们发送消息，浏览网页之类的场景，因为要确保用户信息不丢失，要使用TCP协议，如果在视频聊天或者看直播，可以用UDP协议，因为即使几个画面丢失，对用户的影响也不大。

TCP与UDP区别总结：

1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接。

2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付。

3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的。UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）。

4、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信。

5、TCP首部开销20字节;UDP的首部开销小，只有8个字节。

6、TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道。

补充：

单工

单工就是指A只能发信号，而B只能接收信号，通信是单向的，就象灯塔之于航船——灯塔发出光信号而航船只能接收信号以确保自己行驶在正确的航线上。

半双工

指一个时间段内只有一个动作发生，举个简单例子，一天窄窄的马路，同时只能有一辆车通过，当目前有两量车对开，这种情况下就只能一辆先过，等到头儿后另一辆再开，这个例子就形象的说明了半双工的原理。早期的对讲机、以及早期集线器等设备都是实行半双工的产品。随着技术的不断进步，半双工会逐渐退出历史舞台。

全双工

Full－Duplex Transmissions
指交换机在发送数据的同时也能够接收数据，两者同步进行，这好像我们平时打电话一样，说话的同时也能够听到对方的声音。目前的交换机都支持全双工。

3、TCP头部结构☆

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xqlaqlhW-1620658962491)(https://www.pianshen.com/images/468/e84fe75431647f9db903cbd3d04a71fc.JPEG)]

1、16位端口号：

告知主机该报文段来自哪里（源端口）以及传给哪个上层协议或应用程序（目的端口）的。进行tcp通信时，客户端通常使用系统自动选择的临时端口号，而服务器则使用知名服务端口号。

2、32位序号：

一次tcp通信过程中某一个传输方向上的字节流的每个字节的编号。假设主机A和主机B进行tcp通信，A发送给B的第一个tcp报文段中，序号值被系统初始化为某个随机值ISN。那么在该传输方向上（从A到B），后续的tcp报文段中序号值将被系统设置成ISN加上该报文段所携带数据的第一个在整个字节流中的偏移。例如，某个tcp报文段传送的数据时字节流中的第1025~2048字节，那么该报文段的序号值就是ISN+1025。另一个传输方向（从B到A）的tcp报文段的序号值也具有相同的含义。

3、32位确认号：

用作对另一方发送来的tcp报文段的相应。其值是收到的tcp报文段的序号值加1。假设主机A和主机B进行tcp通信，那么A发送出的tcp报文段不仅携带自己的序号，而且包含对B发送来的tcp报文段的确认号。反之，B发送出的tcp报文段也同时携带自己的序号和对A发送来的报文的确认号。

4、4位头部长度：

标识该tcp头部有多少个32bit字（4字节）因为4位最大能表示15，所以tcp头部最长是60字节。

5、6位标志位（即图中的保留6位）：

标志位有如下几项

• URG标志，表示紧急指针是否有效
• ACK标志，表示确认号是否有效。称携带ACK标志的tcp报文段位确认报文段
• PSH标志，提示接收端应用程序应该立即从tcp接受缓冲区中读走数据，为接受后续数据腾出空间（如果应用程序不将接收的数据读走，它们就会一直停留在tcp缓冲区中）
• RST标志，表示要求对方重新建立连接。携带RST标志的tcp报文段为复位报文段。
• SYN标志，表示请求建立一个连接。携带SYN标志的tcp报文段为同步报文段。
• FIN标志，表示通知对方本端要关闭连接了。携带FIN标志的tcp报文段为结束报文段。

6、16位窗口大小：

是tcp流量控制的一个手段。这里说的窗口，指的是接收通告窗口。它告诉对方本端的tcp接收缓冲区还能容纳多少字节的数据，这样对方就可以控制发送数据的速度。

7、16位校验和：

由发送端填充，接收端对tcp报文段执行CRC算法以校验tcp报文段在传输过程中是否损坏。注意，这个校验不仅包括tcp头部，也包括数据部分。这也是tcp可靠传输的一个重要保障。

8、16位紧急指针：

是一个正的偏移量。它和序号字段的值相加表示最后一个紧急数据的下一个字节的序号。因此，确切的说，这个字段是紧急指针相对当前***的偏移，称为紧急偏移。tcp的紧急指针是发送端向接收端发送紧急数据的方法。

9、16位选项：

​ TCP头部的最后一个选项字段是可变长的可选信息。这部分最多包含40字节，因为TCP头部最长是60字节（其中还包含前面讨论的20字节的固定部分）。典型的TCP头部选项结构如图3-4所示。

​ 选项的第一个字段kind说明选项的类型。有的TCP选项没有后面两个字段，仅包含1字节的kind字段。第二个字段length（如果有的话）指定该选项的总长度，该长度包括kind字段和length字段占据的2字节。第三个字段info（如果有的话）是选项的具体信息。常见的TCP选项有7种，如图3-5所示。

​ kind=0是选项表结束选项。
​ kind=1是空操作（nop）选项，没有特殊含义，一般用于将TCP选项的总长度填充为4字节的整数倍。
​ kind=2是最大报文段长度选项。TCP连接初始化时，通信双方使用该选项来协商最大报文段长度（Max Segment Size，MSS）。TCP模块通常将MSS设置为（MTU-40）字节（减掉的这40字节包括20字节的TCP头部和20字节的IP头部）。这样携带TCP报文段的IP数据报的长度就不会超过MTU（假设TCP头部和IP头部都不包含选项字段，并且这也是一般情况），从而避免本机发生IP分片。对以太网而言，MSS值是1460（1500-40）字节。
​ kind=3是窗口扩大因子选项。TCP连接初始化时，通信双方使用该选项来协商接收通告窗口的扩大因子。在TCP的头部中，接收通告窗口大小是用16位表示的，故最大为65?535字节，但实际上TCP模块允许的接收通告窗口大小远不止这个数（为了提高TCP通信的吞吐量）。窗口扩大因子解决了这个问题。假设TCP头部中的接收通告窗口大小是N，窗口扩大因子（移位数）是M，那么TCP报文段的实际接收通告窗口大小是N乘2M，或者说N左移M位。注意，M的取值范围是0～14。我们可以通过修改/proc/sys/net/ipv4/tcp_window_scaling内核变量来启用或关闭窗口扩大因子选项。
和MSS选项一样，窗口扩大因子选项只能出现在同步报文段中，否则将被忽略。但同步报文段本身不执行窗口扩大操作，即同步报文段头部的接收通告窗口大小就是该TCP报文段的实际接收通告窗口大小。当连接建立好之后，每个数据传输方向的窗口扩大因子就固定不变了。关于窗口扩大因子选项的细节，可参考标准文档RFC 1323。
​ kind=4是选择性确认（Selective Acknowledgment，SACK）选项。TCP通信时，如果某个TCP报文段丢失，则TCP模块会重传最后被确认的TCP报文段后续的所有报文段，这样原先已经正确传输的TCP报文段也可能重复发送，从而降低了TCP性能。SACK技术正是为改善这种情况而产生的，它使TCP模块只重新发送丢失的TCP报文段，不用发送所有未被确认的TCP报文段。选择性确认选项用在连接初始化时，表示是否支持SACK技术。我们可以通过修改/proc/sys/net/ipv4/tcp_sack内核变量来启用或关闭选择性确认选项。
​ kind=5是SACK实际工作的选项。该选项的参数告诉发送方本端已经收到并缓存的不连续的数据块，从而让发送端可以据此检查并重发丢失的数据块。每个块边沿（edge of block）参数包含一个4字节的序号。其中块左边沿表示不连续块的第一个数据的序号，而块右边沿则表示不连续块的最后一个数据的序号的下一个序号。这样一对参数（块左边沿和块右边沿）之间的数据是没有收到的。因为一个块信息占用8字节，所以TCP头部选项中实际上最多可以包含4个这样的不连续数据块（考虑选项类型和长度占用的2字节）。
​ kind=8是时间戳选项。该选项提供了较为准确的计算通信双方之间的回路时间（Round Trip Time，RTT）的方法，从而为TCP流量控制提供重要信息。我们可以通过修改/proc/sys/net/ipv4/tcp_timestamps内核变量来启用或关闭时间戳选项。

4、IP头部结构

IP协议详解之头部结构

IPv4头部结构

长度通常为20字节，除非有可变长的选项部分。

横着一行为32个bit，为四个字节。

4位版本号:

指定IP协议的版本。对IPv4来说，为4。

4位头部长度:

标识该IP头部有多少个32bit(即多少行),四位最大表示15，所以IP头部最长为60字节。

8位服务类型:

包括一个三位的优先权字段(现在已忽略)四位的TOS字段和一位保留字段(保留需置0).四位的TOS字段分别表示：最小延时，最大吞吐量，最高可靠性和最小费用。这四位中最多只有一位置1。应用程序根据需要设置(比如ssh需要最小延时，ftp需要最大吞吐量)。

16位总长度:

是指整个IP数据报的长度，以字节为单位，因此IP数据报最大长度为65535-1字节。但由于MTU的限制，长度超过MTU的数据报都将被分片传输，所以实际传输的IP数据报的长度都远远没有达到最大值。

16位标识：

唯一地标识主机发送的每一个数据报。其初始值由系统随机生成，每发送一个数据报，其值就加一。该值在数据报分片时被复制到每个分片中，因此同一个数据报的所有分片都具有相同的标识符。

3位标志字段：

第一位保留。第二位标识禁止分片。设置后，IP将不对该数据报分片，当该数据报长度超过MTU时，IP模块将丢弃该数据包并返回一个ICMP差错报文。第三位表示更多分片。除了数据报的最后一个分片外，其他分片都要把该位置1.

13位分片偏移:

是分片相对原始IP数据报开始处(仅指数据部分)的偏移。实际的偏移值是该值左移三位(乘8)后得到的。因此，每个IP分片的数据部分的长度必须是8的整数倍。

8位生存时间TTL(time to live)：

是数据报到达目的地之前允许经过的路由器跳数。发送端设置(通常是64)。数据报每经过一次路由，该值就被路由器减一，为零时，路由器将丢弃该数据报，并向源端发送一个ICMP差错报文。TTL可以防止数据报陷入路由循环。

8位协议：

用来区分上层协议。/etc/protocols文件定义了所有上层协议对应的字段的数值。例如，ICMP是1，TCP是6，UDP是17。

16位头部校验和：

由发送端填充，接收端对其使用CRC算法检验头部在数据传输过程中是否损坏。

32位源端IP地址：

用来表示IP数据报的发送端

32位目的端IP地址：

用来表示IP数据报的接收端
选项字段：
  是可变长的可选信息。最多包含40字节，可用的选项有：
  记录路由：将途径的路由器的ip地址填入选项部分，用于跟踪数据报的传递路径。
  时间戳：告诉每个路由器将数据报被转发的时间(或时间与IP地址对)填入IP头部的选项部分，这样就可以测量途径路由之间数据报传输的时间。
  松散路由选择：指定路由IP地址列表，数据包发送过程必须经过其中所有路由器。
  严格路由选择：数据报只能经过被指定的路由器。

5、TCP要三次握手，四次挥手 ☆

第一次握手：

主机A发送位码为SYN=1，随机产生 是seq number=1234567的数据包到服务器，主机B由SYN=1知道，A要求建立联机。

第二次握手：

主机B收到请求后要确认联机信息，向A发送ack number=(主机A的seq+1)，SYN=1，ACK=1，随机产生seq=7654321的包。

第三次握手：

主机A收到后检查ack number是否正确，即第一次发送的seq number+1，以及位码ACK是否为1，若正确，主机A会再发送seq number、ack number=（主机B的seq+1）和ACK=1，主机B收到后确认seq值与ACK=1则连接建立成功。完成三次握手，主机A与主机B开始传送数据。（结合图理解）

为什么三次握手：

**主要为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。**如A发出连接请求，但因连接请求报文丢失而未收到确认，于是A再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。但是第一个丢失的报文只是在某些网络节点长时间滞留了，延误到连接释放以后的某个时间才达到B，此时B误认为A又发出了一次新的连接请求，于是就向A发出确认报文段，同意建立连接，如果不采用三次握手，只要B发出确认，就建立·新的连接了，此时A不理睬B的确认且不发送数据，则B一直等待A发送数据，浪费资源。

为什么四次挥手？

因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端“你发的FIN报文我我收到了”。只有等到我Server端的所有报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

客户端发送了FIN连接释放报文之后，服务器收到了这个报文，就进行了CLOSE-WAIT状态。这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器会发送FIN连接释放报文。

6、简述TIME_WAIT和CLOSE_WAIT☆

TIME_WAIT(主动关闭连接)

​ 客户端接收到服务器端的FIN报文后进入此状态，此时并不是直接进入CLOSED状态，还需要等待一个时间计时器设置的时间2MSL。这么做有两个理由：一是确保最后一个确认报文能够到达。如果服务端没收到客户端发送来的确认报文，那么就会重新发送连接释放请求报文，客户端等待一段时间就是为了处理这种情况的发生。二是等待一段时间是为了让本连接的持续时间内所产生的所有报文都从网络中消失，从而确保下一个新的连接不会出现旧的连接请求报文。

CLOSE_WAIT(被动关闭连接)

​ 服务器端收到客户端的发送的FIN，则按照TCP实现发送ACK，因此进入CLOSE_WAIT状态。但如果服务器端不执行close(),就不能由CLOSE_WAIT迁移到LAST_ACK,则系统中会存在很多CLOSE_WAIT状态的连接。

扩展:TCP通信过程中time_wait和close_wait产生过多的原因和解决。

7、TCP协议-如何保证传输可靠性☆

网络基础：TCP协议-如何保证传输可靠性

TCP/IP入门(3) --传输层

TCP协议保证数据数据传输可靠性的方式主要有：

校验和:

确认应答和序列号:

超时重传：

简单理解就是发送方在发送完数据后等待一个时间，时间到达没有接收到ACK报文，那么对刚才发送的数据进行重新发送。

连接管理：三次挥手和四次握手

流量控制：

TCP根据接收端对数据的处理能力，决定发送端的发送速度，这个机制就是流量控制。TCP协议的报头信息当中，有一个16位字段的窗口大小，发送方根据ACK报文里的窗口大小的值的改变进而改变自己的发送速度。滑动窗口：https://blog.csdn.net/yao5hed/article/details/81046945

拥塞控制：慢开始，拥塞控制，快重传，快恢复

拥塞控制的一般原理

在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变换，叫做拥塞。

拥塞控制和流量控制的区别：

拥塞控制往往是一种全局的，防止过多的数据注入到网络之中，而TCP连接的端点只要不能收到对方的确认信息，猜想在网络中发生了拥塞，但并不知道发生在何处，因此，流量控制往往指点对点通信量的控制，是端到端的问题。

当提供的负载继续增大到某一数值时，网络的吞吐量就下降到零，网络无法工作，产生所谓的死锁。

拥塞控制可以分为开环控制和闭环控制

1. 开环控制，在设计网络时把因素考虑到

2. 闭环控制，基于反馈环路，使用拥塞的信息来进行调整网络

过程：

几种拥塞控制方法
总共四种：慢开始，拥塞避免，快重传，快恢复

1.慢开始和拥塞避免

发送方维持一个叫做拥塞窗口cwnd，根据网络来进行动态的调整大小，网络拥塞的时候，路由器会丢弃报文，当发送方没有按时收到确认报文，那么就知道网络发生了拥堵。

现在结合拥塞窗口cwnd的变化来看一下上述两个方法

慢开始的“慢”指的是，初始cwnd=1（此时表示的是报文段的个数，而不是真正传输时使用的字节流）

我们来简单的论一下这个过程：

1. 开始时发送方cwnd=1，发送报文段M1，如果收到确认M1，那么此时增大cwnd=2，并发送M2，M3

2. 要注意，发送方每收到一个确认报文段，cwnd*2（不包括缺失重传的确认）也就是说，每经过一个传输伦次（RTT时间），cwnd加倍。

   但是，为了防止拥塞窗口cwnd增长过大而引起网络拥塞，设置一个慢开始门限ssthresh。

   1. 当cwnd<ssthresh，使用上述的慢开始算法

   2. 当cwnd>ssthresh，停止使用慢开始，使用拥塞避免算法

   3. 当cwnd==ssthresh，两者都可以使用

   那么理所当然的，现在我们要来看一下拥塞避免算法。

拥塞避免算法的思路是让拥塞窗口cwnd缓慢增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd+1，而不是加倍（也就是收到两个，四个确认，仍然+1），这样cwnd就按线性增大

2.快重传和快恢复

快重传的核心：

当接收方收到了一个失序的报文，马上报告给发送方，我没收到，赶紧重传（天下武功唯快不破），加入M2收到了，M3没有收到，之后的M4,M5,M6又发送了，此时接收方一共连续给发送方反馈了4个M2确认报文。那么快重传规定，发送方只要连续收到3个重复确认，立即重传对方发来的M3

那么我们再来看一下快恢复

两个要点：

1.当发送方连续收到三个重复确认，执行乘法减小，cwnd减半，并设置为新的ssthresh值。

2.由于发送方可能认为网络现在没有拥塞，因此与慢开始不同，把cwnd值设置为ssthresh减半之后的值，然后执行拥塞避免算法，线性增大cwnd

其实呢，对于接收方也是用限额的，有一个rwnd，也就是接收窗口，那么实际上，发送方窗口的上限=min(rwnd,cwnd)

8、DNS域名解析

DNS占用53号端口，同时使用TCP和UDP协议。

DNS区域传输的时候使用TCP协议：

（1）辅域名服务器会定时（一般三个小时），向主域名服务器进行查询以便了解数据是否有变动。如有变动，会执行一次区域传送，进行数据同步。区域传送使用TCP而不是UDP，因为数据同步传送的数据量比一个请求应答的数据量要多的多。

（2）TCP是一种可靠连接，保持了数据的准确性。

域名解析使用UDP协议：

客户端向DNS服务器查询域名，一般返回的内容都不超过512字节，用UDP传输即可。不用经过三次握手，这样DNS服务器负载更低，响应更快。理论上说，客户端也可以指定向DNS服务器查询时用TCP，但事实上，很多DNS服务器进行配置的时候，仅支持UDP查询包。

9、HTTP报文结构和状态码☆

（1）请求格式

请求行，请求头，空行，请求数据。

（2）返回格式（状态码）

状态行，消息报头，响应报文。

Http/1.1 200 OK

Date: Sat,31 Dec 2005 23:59:59 GMT

Content-Type:text/html;charset=ISO-8859-1

Content-Length: 122

<html>
    <head>
        <title>Wrox Homepage</title>
    </head>
    <body>
        <!--body goes here-->
    </body>
</html>

状态码：

状态码	类别	含义
1XX	Informational(信息性状态码)	接收请求正在处理
2XX	Success(成功状态码)	请求正常处理完毕
3XX	Redirection(重定向码)	需要进行附加操作以完成请求
4XX	Client Error(客户端错误状态码)	服务器无法处理请求
5XX	Server Error(服务器错误状态码)	服务器处理请求出错

常见状态码：

200 OK：客户端请求成功

301 Moved Permanently：永久性重定向

302 Found：临时性重定向

400 Bad　Request : 客户端请求有语法错误，不能被服务端请求所理解。

401 Unauthorized： 请求未经授权，这个状态码必须和WWW-Authenticate报头域一起使用。

403 Forbidden： 服务器收到请求，但是拒绝提供服务。

404 Not Found：请求资源不存在，存在例子：输入了错误的URL。

500 Internal Server Error：服务器发生不可预期的错误。

503 Server Unavailable：服务器当前不能处理客户端的请求，一段时间后可能恢复正常,e.g.:HTTP/1.1 200(CRLF)

（3）Http/1.1的新特性。默认是长连接。

支持流水线

支持同时打开多个TCP连接

新增状态码100：到目前为止都正常，客户端可以继续发请求或者忽略这个响应。

支持分块传输编码：可以把数据分割成多块，让浏览器逐步显示页面。

新增缓存处理指令 max-age：有效期来指定cookie的持久性。

（4）缓存问题

Expires、Cache-Control、Last-Modified和Etag总结

10、GET和POST比较 ☆

	get	post
作用	获取资源	传输实体主体
参数	以查询字符串出现在URL中	存储在实体主体中
修改性	HTTP方法不会改变服务器状态，GET方法是安全的。	目的是传送实体主体内容，这个内容可能是用户上传的表单数据，上传成功后可能会服务器可能把这个数据存储到数据库中，因此状态就发生时了改变，从而POST并不安全
幂等性	幂等性 连续调用多次，客户端接收到的结果都是一样的	不是幂等性的，如果调用多次，就会增加多行记录
可缓存	可缓存（响应状态码和cache-Control保证可缓存的）	post不可缓存
底层	对于GET请求，浏览器会把Http header和data一并发送出去，服务器响应200 OK（返回数据）	对于Post，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）

延伸：

HTTP请求的方法：

HTTP/1.1协议中共定义了八种方法（有时也叫“动作”），来表明Request-URL指定的资源不同的操作方式
HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法。
HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法

1、OPTIONS
返回服务器针对特定资源所支持的HTTP请求方法，也可以利用向web服务器发送‘*’的请求来测试服务器的功能性
2、HEAD
向服务器索与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以再不必传输整个响应内容的情况下，就可以获取包含在响应小消息头中的元信息。
3、GET
向特定的资源发出请求。注意：GET方法不应当被用于产生“副作用”的操作中，例如在Web Application中，其中一个原因是GET可能会被网络蜘蛛等随意访问。Loadrunner中对应get请求函数：web_link和web_url
4、POST
向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。 Loadrunner中对应POST请求函数：web_submit_data,web_submit_form
5、PUT
向指定资源位置上传其最新内容
6、DELETE
请求服务器删除Request-URL所标识的资源
7、TRACE
回显服务器收到的请求，主要用于测试或诊断
8、CONNECT
HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
注意：
1）方法名称是区分大小写的，当某个请求所针对的资源不支持对应的请求方法的时候，服务器应当返回状态码405（Mothod Not Allowed）；当服务器不认识或者不支持对应的请求方法时，应返回状态码501（Not Implemented）。
2）HTTP服务器至少应该实现GET和HEAD/POST方法，其他方法都是可选的，此外除上述方法，特定的HTTP服务器支持扩展自定义的方法。

11、Cookie作用，安全性问题和Session的比较。☆

（1）Cookie是服务器发送到用户浏览器并保存到本地的一小块数据。

它会在浏览器之后向同一服务器再次发起请求时被携带上，用于告知服务端两个请求是否来自同一浏览器。可以用来做会话状态管理（如用户登录状态）、个性化设置、浏览器行为跟踪。可能被浏览器禁用。

（2）Session 存储在服务器端，存储在服务器端的信息更加安全。

使用Session维护用户登录状态的过程如下：（需要cookie作为传输机制）

用户进行登录时，用户提交包含用户名和密码的表单，放入HTTP请求报文中：

服务器验证该用户名和密码，如果正确则把用户信息存储到Redis中，它在Redis中的Key称为Session Id；

服务器返回的响应报文的Set-Cookie首部字段包含了这个SessionID，客户端收到了响应报文之后将该Cookie值存入浏览器中；

客户端之后对同一个服务器进行请求时会包含该Cookie值，服务器收到之后提取出SessionID，从Redis中取出用户信息，继续之前的业务操作。

（3）二者区别

对于大型网站，如果用户的所有信息都存储在session中，那么开销非常大，不建议。

	Cookie	Session
存储内容	只能存储ASCII码字符串	可以存取任何类型的数据
存在位置	客户端，临时文件夹	服务端
安全性	有安全隐患，通过拦截或者本地文件得到你的Cookie进行攻击	相对安全
大小限制	有大小限制，单个不超过4k，浏览器Cookie个数也有限制	无限制，和服务器内存相关
生命周期	可以设置，默认是一次会话的时间	间隔的，关闭服务器会造成周期结束

12、短连接与长连接、流水线

长连接和短连接：

HTTP/1.1开始默认是长连接的，如果要断开连接，需要有客户端或者服务器端提出断开，使用Connnection：close：长连接只需要建立一次TCP连接就能进行多次HTTP通信。

HTTP/1.1之前默认是短连接的，如果需要使用长连接，则使用Connection：Keep-Alive。短连接：客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。

流水线：

默认情况下，HTTP请求时按顺序发出的，下一个请求只有在当前请求收到响应之后才会被发出。由于会受到网络延迟和带宽的限制，在下一个请求被发送到服务器之前，可能需要等待很长时间。

流水线是在同一条长连接上发出连续的请求，而不用等待响应返回，这样可以避免连接延迟。

13、HTTP的安全性问题

1、安全问题：

1. 使用明文进行通信，内容可能会被窃听。
2. 不验证通信方的身份，通信方的身份有可能遭遇伪装
3. 无法证明报文的完整性，报文有可能遭篡改。

2、HTTPS加密

通过使用SSL，HTTPS具有了加密（防窃听）、认证（防伪装）、完整性保护（防篡改）。

HTTPS采用混合加密机制，使用非对称密钥加密用于传输对称密钥来保证传输过程的安全性，之后使用对称密钥加密来保证通信过程的效率。

HTTPS加密过程：

1. 客户使用Https的URL访问Web服务器，要求与Web服务器建立SSL连接。

2. Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。

3. 客户端的浏览器与Web服务器开始协商SSL连接的安全等级，也就是信息加密的等级。

4. 客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。

5. Web服务器利用自己的私钥解密出会话密钥。

6. Web服务器利用会话密钥加密与客户端之间的通信。

缺点：

因为需要进行加密解密等过程，因此速度会更慢。

需要支付证书授权的高额费用。

14、HTTP与FTP的异同点

1、同：

（1）都是应用层协议；

（2）都运行在TCP上，即都使用TCP(而不是UDP)作为其支撑的运输层协议。

2、异：

（1）HTTP是超文本传输协议，是面向网页的，而FTP是文件传输协议，是面向文件的。

（2）HTTP的控制信息是带内（in-band）传送的，而FTP的控制信息是带外（out-of-band）传输的。

（3）HTTP是无状态的，而 FTP服务器必须在整个会话期间保留用户的状态（state）信息。

（4）HTTP既可以使用非持久连接，也可以使用持久连接，而FTP使用两个并行的TCP连接来传输文件，一个是控制连接（control connection），一个是数据连接（data connection）。FTP的控制链接是持久连接，数据连接是非持久连接。

15、输入网址发生事情

1、浏览器可以查找该域名的IP地址。

1、回车键按下后，浏览器会对输入的地址数据进行解析：
　　1.1、检查输入的URL是http协议，请求资源是对应主机名网站主页。
　　1.2、然后检查浏览器的严格安全传输列表（ HSTS列表 ），如果网站在列表中，则浏览器直接使用https协议进行传输，否则直接使用http协议传输，或者先使用http协议向网站服务器发送一个请求，服务器返回浏览器只能以https协议进行，则接下来仍然只以https协议来进行传输。
　　1.3、然后检查输入地址中是否有非ASCII码的unicode字符，如果有的话进行字符转换。
　　1.4、当协议或主机名不合法时，浏览器会将地址栏中输入的内容传递给默认的搜索引擎。

2、然后进行DNS递归查询
　　2.1、DNS查询过程中，首先在缓存中进行查询，找到直接返回结果否则
　　2.2、再使用gethostbynme库函数进行查询，库函数查询过程中，首先到hosts中进行检查，查看域名是否在本地hosts文件中，找到直接返回结果，如果没有记录且库函数查询也没有记录则
　　2.3、以上查询均未果，则会向DNS服务器发送一条DNS查询请求。查询DNS服务器通常是在本地路由器或者ISP的缓存DNS服务器上进行，如果对应记录存在，则返回该映射地址，并且该地址会被标记为非权威服务器应答标签，如果对应记录不存在，则会递归向高层 DNS 服务器做查询，直到返回最终结果。
　　2.4、如果DNS查询失败，则返回无法解析DNS地址，停止，否则浏览器根据查询到的对应ip地址进行下一步操作，即使用套接字进行数据访问。

2、浏览器根据解析到的IP地址向web服务器发送一个HTTP请求。

3、使用套接字进行数据访问
　　3.1、浏览器获得目标IP地址，以及URL中给出的端口号（http 协议默认端口号是 80， https 默认端口号是 443），调用系统库函数socket，请求一个TCP流套接字。
　　3.2、该请求首先被交给传输层，封装成TCP segment，然后被送往网络层，添加目标服务器IP地址以及本机的IP地址，封装成TCP packet，再接下来会进入链路层，在封包中加入frame头部，包含本机网卡的MAC地址和网关MAC地址等，形成最终的TCP封包。
　　3.3、TCP封包完成之后，会通过以太网等网络进行传输到目标地址。

4、建立TCP连接
　　建立TCP连接会进行三次握手的过程，然后进行发送HTTP请求过程和接收过程。
　　4.1、进行三次握手，首先向服务器发送一个syn报文，其中syn=1，seq number=1022(随机)；
　　4.2、服务器接收到syn报文，根据syn=1判断客户端请求建立连接，并返回一个syn报文，为第一次握手，其中ack number=1023(客户端seq number+1)，seq number=2032(随机)，syn=1，ack=1；
　　4.3、客户端根据服务器的syn报文，确认其ack number是否与上一次发送的seq number+1相等，且ack=1，确认正确，则回应一个ack报文，为第二次握手，即ack number=2033(服务器seq number+1)，ack=1，
　　4.4、服务器根据接收到的ack报文，确认ack number是否与上一次发送的seq number+1相等，并且ack=1，确认正确，则建立连接，进入Established状态，为第三次握手。
　　4.5、建立TCP连接后，会使用HTTP协议发送HTTP的GET请求，服务器处理请求返回资源数据。

3、服务器收到请求并进行处理。

4、服务器返回一个响应（响应状态码)

5、浏览器对该响应进行编码，渲染显示。

5、浏览器处理数据
　　5.1、再接收到所请求的资源之后，浏览器会对接收到的html、css、js等数据根据标准格式进行解析。
　　5.2、然后会通过构建和遍历DOM节点树，进行各个节点的渲染计算，最后进行GPU的渲染布局和绘制步骤等。

报文，其中syn=1，seq number=1022(随机)；
　　4.2、服务器接收到syn报文，根据syn=1判断客户端请求建立连接，并返回一个syn报文，为第一次握手，其中ack number=1023(客户端seq number+1)，seq number=2032(随机)，syn=1，ack=1；
　　4.3、客户端根据服务器的syn报文，确认其ack number是否与上一次发送的seq number+1相等，且ack=1，确认正确，则回应一个ack报文，为第二次握手，即ack number=2033(服务器seq number+1)，ack=1，
　　4.4、服务器根据接收到的ack报文，确认ack number是否与上一次发送的seq number+1相等，并且ack=1，确认正确，则建立连接，进入Established状态，为第三次握手。
　　4.5、建立TCP连接后，会使用HTTP协议发送HTTP的GET请求，服务器处理请求返回资源数据。

3、服务器收到请求并进行处理。

4、服务器返回一个响应（响应状态码)

5、浏览器对该响应进行编码，渲染显示。

5、浏览器处理数据
　　5.1、再接收到所请求的资源之后，浏览器会对接收到的html、css、js等数据根据标准格式进行解析。
　　5.2、然后会通过构建和遍历DOM节点树，进行各个节点的渲染计算，最后进行GPU的渲染布局和绘制步骤等。

6、页面显示完成后，浏览器发送异步请求。