1、网络七层协议包含，物理层、数据链路层、网络层（ip协议）、传输层（TCP传输控制协议、UDP用户数据报协议）、会话层、表示层、应用层（http协议）。是一个提供的概念架构协议。
2、TCP/IP协议，四层架构参考模型。包含链路层、网络层、传输层、应用层。TCP/IP协议是协议群的统称，其包含tcp、udp、ftp、Telnet、http等等，这些都属于TCP/IP协议。
3、传输控制协议TCP是什么？
TCP协议是传输层的协议。面向连接的、可靠的、基于字节流的传输层通信协议。将应用层的数据流分割成报文段并发送给目标节点的TCP层。数据包都有序号，对方收到则发送ack确认，未收到则重传。使用校验和来校验数据在传输过程中是否有误。
IP协议是无连接的通信协议，不会占用两个正在通信的计算机之间的通信线路。ip降低了对网络线路的需求，每条线可以同时满足许多不同计算机之间的通信需要，通过ip消息或者其他数据会被分割为较小的独立的包，并通过internet网在计算机之间进行传送，ip负责将它的包路由到它的目的地，但是ip协议没有做数据包是否按照顺序发送，或者包是否被破坏，所以Ip数据包是不可靠的。需要由ip的上层协议做出控制。
4、何为TCP的三次握手？
当应用程序通过tcp和另一个应用程序进行通信的时候，它会发送一个通信请求，这个请求必须被送到一个确切的地址，在双方握手之后，tcp将在两个应用之间建立一个全双工的通信，这个全双工的通信将占用两个计算机之间的通信线路，直到被一方或者双方关闭为止。全双工的含义就是计算机A可以给另一个计算机B发送信息，在发送信息的同时，而另一个计算机B也可以给计算机A回发信息。握手是为了建立连接，TCP三次握手的流程图如下所示：
4.1）、三次握手详细介绍如下所示：
初始状态：开始状态客户端和服务器都是CLOSE关闭状态。当客户端主动打开，服务器端被动打开。刚开始的时候TCP服务器进程先创建传输控制块tcb，时刻准备接收其它进程发送过来的请求，此时服务器端进入Listen监听状态。
1）、第一次握手：刚开始的时候TCP客户端进程也是先创建传输控制块tcb，向服务器发送连接请求报文，SYN=1，seq=x就是报文头里面tcp flags 里面的同步序号SYN=1，同时选择一个初始序号seq=x，x是任意正整数的值。此时TCP客户端进程进入了一个SYN-SENT同步已发送的状态。此时发送过去的数据包即报文段被称为SYN报文段，它是不可以携带数据的。但是会消耗掉一个序号，这便是第一次握手了。
2)、当服务器接收到请求报文的时候，如果同意连接，会发送确认报文，确认报文中包含了TCP flags两个标志位字段SYN=1，ACK=1，确认号是ack=x+1。由于客户端发送SYN报文中的seq=x，服务器端为了回应客户端，要回应和x相关的信息，但是客户端发送SYN报文中的seq=x消耗了一个序号，因此服务器端发送的确认号便成了ack=x+1，同时为了自己的缓存初始化一个序列号即seq=y。此时服务器进入了SYN-RCVD状态即同步已收到的状态。该报文也是不可以携带数据的，并且同样需要消耗一个序号，这便是第二次握手了。
3）、当TCP客户进程收到确认报文之后，还要向服务器端给出一个确认，确认报文的ACK=1。ack=y+1，因为服务器发送的报文里面seq=y，而客户端为了回应服务器端，要回应和y相关的信息，但是服务器端发送报文中的seq=y消耗了一个序号，因此客户端发送的确认号便成了ack=y+1。seq=x+1，是因为第二次握手的时候，服务器端响应客户端的时候以将ack=x+1即x序号加1，因此此时第三次握手的时候seq=x+1。此时客户端和服务器端进入ESTAB-LISHED状态即连接已建立。这便是第三次握手了。
4.2）、面试回答，握手是为了建立连接，TCP的三次握手流程大致如下所示：
在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。切记，syn：同步序列编号(Synchronize Sequence Numbers)。
1）、第一次握手：建立连接时，客户端发送SYN包(syn=x)到服务器，并进入SYN_SEND状态即同步已发送，等待服务器确认。
2）、第二次握手：服务器收到SYN包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态即同步已收到。
3）、第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送完毕，客户端和服务器进入ESTAB LISHED状态即连接已建立，完成三次握手。
5、为什么需要三次握手才能建立起连接呢？
答：为了初始化Sequence Number的初始化值。通信的双方要互相通知对方自己的初始化的Sequence Number值。即seq=x和seq=y，seq值要作为以后的数据通信的序号，以保证应用层接收到的数据不会因为网络上的传输问题而乱序，即Tcp会用这个序号进行拼接数据。因此在服务器回发它的Sequence Number即第二次握手之后还需要发送确认报文给服务器，告诉服务器客户端已经收到你的初始化Sequence Number值。
6、首次握手的隐患SYN超时。问题起因分析。
答：Server服务器端收到Client客户端发送的SYN，Server服务器端回复Client客户端SYN-ACK的时候，如果此时Client客户端掉线了，Server服务器端未收到Client客户端的ACK确认。那么该连接就处于一个中间状态，即未连接成功也未连接失败状态。此时Server服务器端不断重试直至超时，Linux默认重试5次，重试间隔从1秒开始，每次翻倍，等待63秒钟，tcp才会断开连接。此时服务器可能遭受SYN Flood攻击的风险。
针对SYN Flood攻击风险的防护措施。比如恶意程序给服务器发送SYN报文，发送以后就进行了下线，然后服务器默认等待63秒才会断开，攻击者就会将服务器的SYN连接的队列耗尽，让正常的连接请求不能处理。Linux系统给出了一个方案，当SYN队列满后，通过tcp_syncookies参数回发SYN Cookie。TCP根据源地址端口，目标目的端口，时间戳生成一个特殊的Sequence Number即SYN Cookie回发给客户端。如果是攻击者是不会有响应的，若为正常连接则Client客户端会回发服务器端SYN Cookie，直接建立连接。通过SYN Cookie创建的连接，即使现在SYN队列满后，本次连接请求不在队列中，也可以创建连接。
如果建立连接后，Client客户端出现故障怎么办呢，其实TCP设置保活机制，在一段时间内，该时间被称为保活时间keep alive time，在这段时间内，连接处于非活动状态，开启保活功能的一端将向对方发送保活探测报文。向对方发送保活探测报文，如果发送端未收到响应报文，如果在保活时间内即提前配置好的keep alive time则继续发送。直到尝试次数达到保活探测数仍未收到响应则中断连接。对方直接将被确认为不可达，连接即被中断。
7、TCP的四次挥手，挥手是为了终止连接，就是终止一个TCP连接的时候需要客户端和服务器端总共发送4个包，以确认连接的断开。客户端或者服务器端任意一方触发close断开连接。TCP四次挥手的流程图如下所示：
7.1)、四次挥手详细介绍如下所示：
1）、数据传输完毕以后呢，客户端和服务器端都可以释放连接，最开始的时候，客户端和服务器端都处于ESTAB-LISHED状态即连接已建立。当客户端主动关闭，服务器端被动关闭。首先客户端进程发送连接释放报文，并且停止发送数据，在该数据的报头中tcp flags中的FIN=1，假设客户端定义的序列号seq=u，该值等于前面ESTAB-LISHED状态下数据最后一次发送已经传送过来的数据最后一个字节的序号加一。此时客户端进入FIN-WAIT-1的状态即中止等待1的状态（FIN-WAIT-1是finish-wait-1的缩写）。TCP规定，即使FIN报文段不携带任何数据，也要消耗一个序列号。即服务器端回值的时候ack=u+1。这就是第一次挥手。
2）、当服务器端收到连接释放报文的时候，也要发出确认报文即ACK=1，作为回应ack=u+1，Sequence Number序列号等于u+1。并且携带了自己的序列号seq=v。此时服务器端进入了CLOSE-WAIT状态即关闭等待。这就是第二次挥手。
3）、TCP服务器通知高层的应用进程，客户端要释放和服务器通信的连接了，此时会处于半关闭的状态，即客户端无数据要发送了，但是服务器端若要给客户端发送数据，客户端还是可以接收的，此半关闭状态持续的时间就是等于CLOSE-WAIT状态持续的时间。客户端收到服务器端的确认请求后，也就是第二次挥手的时候，此时客户端进入了FIN-WAIT-2状态即中止等待2状态。等待服务器发送释放连接报文，等待服务器端发送第三次挥手的请求。因此这段时间内，还有可能需要接收服务器端发送的数据请求，当服务器将最后的数据发送完毕以后，就会向客户端发送连接释放报文，即FIN=1，ack还是等于u=1即ack=u+1，由于在半关闭的状态，服务器很可能发送了一些数据，假定此时的序号seq=w，此时服务器进入了LAST-ACK状态即最后确认的状态。等待客户端的最终确认，这就是第三次挥手。
4）、当客户端收到服务器端释放连接报文的时候，必须发出确认，即ACK=1，将服务器发送的w加1，即ack=w+1，由客户端回发给服务器端。此时客户端的需要假定现在是seq=u+1。此时客户端进入了TIME-WAIT状态即时间等待的状态，此时tcp连接还未释放，必须等待时间是2MSL（2乘以MSL时间，MSL是最长报文段寿命）。此时连接才真正释放，才进入到了CLOSE状态。当服务器端接收到客户端的确认请求以后立即进入了CLOSE状态即关闭状态。说明了服务器端结束TCP连接时间比客户端结束TCP连接的时间稍早一些。这就是第四次挥手。
7.2）、面试回答，挥手是为了断开连接，TCP采用四次挥手来释放连接。TCP的四次挥手流程大致如下所示：
1）、第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态即中止等待1的状态。
2）、第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态即关闭等待状态。
3）、第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态即最后确认状态。
4）、第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态即时间等待状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态即关闭状态，完成四次挥手。
8、为什么会有TIME_WAIT状态呢。
答：TIME-WAIT时间等待状态到CLOSE关闭状态，有一个超时设置，这个超时设置是2乘以MSL。为什么要等待这一段时间呢，TIME-WAIT状态主要是要确保有足够的时间让对方收到ACK包，如果被动关闭的哪一方没有收到ACK确认，就会触发被动端重发FIN包（FINISH包）一来一去正好是2乘以MSL。也避免了新旧连接混淆，不让这个连接和后面的连接混到一起。
9、为什么需要四次挥手才能断开连接呢？
答：全双工的意思是允许数据在两个方向上同时传输，即在同一时间服务器可以发送给客户端，客户端也可以发送数据给服务器。因为TCP是全双工，发送方和接收方都需要FIN报文和ACK报文，也就是说发送方和接收方各自需要两次挥手即可，只不过有一方是被动的，所以，看上去就变成了四次挥手。
10、服务器频繁出现大量CLOSE_WAIT状态的原因？
答：问题的其中一个表现是客户端一直在请求，但是返回给客户端的信息是异常的，即客户端没有收到过请求。服务器保存了大量的CLOSE_WAIT状态，只有一种情况，那就是在客户端发送一个FIN报文的时候，服务器这边没有进一步发送ACK确认或者FIN报文已确认。换句话说就是对方关闭socket连接，程序没有检测到或者程序本身忘记需要关闭连接，该资源一直被程序占用着（我方忙于读或者写），没有及时关闭连接。遇到这种情况（可能是程序中有Bug哦），要及时检查代码，特别是释放资源的代码。或者是配置出现了问题，要检查配置，特别是处理请求的线程配置。
11、TCP与UDP的区别。TCP (Transmission Control Protocol)和UDP(User Datagram Protocol)协议属于传输层协议。
UDP的特点，如下所示：
a）、UDP的特点是面向非连接的协议，传输数据之前，源端和目标端没有创建连接。当想要传输的时候，就抓取来自应用程序的数据，并尽可能快的将它传输到网络上，在发送端，UDP传输数据的速度仅仅是受应用程序生成数据的速度、计算机的能力、传输带宽的限制影响，在接收端，UDP把每个消息段放到队列中，应用程序每次从队列中读取消息段。
b）、UDP传输数据的时候不建立连接，所以不维护连接状态，支持同时向多个客户端传输相同的消息。
c）、UDP数据包报头只有8个字节，额外开销较小。TCP包报头需要22个字节。
d）、UDP吞吐量只受限于数据生成速率、传输速率以及机器性能（源端和终端机器的性能）。
e）、UDP尽最大努力交付，不保证可靠交付，不需要维护复杂的链接状态表。
f）、UDP面向报文，不对应用程序提交的报文信息进行拆分和合并。
12、TCP的滑动窗口简述。
1）、RTT是发送一个数据包到收到对应的ACK，所花费的时间。即源端发送一个数据包，到目标端回应一个ACK所花费的时间。
2）、RTO是重传时间间隔。RTO是本次发送当前数据包预留的超时时间，RTO是根据RTT计算出来的。TCP在发送一个数据包的时候，会启动一个重传定时器，RTO就是这个重传定时器重传时间。通俗的讲，预先计算一个定时器重传时间，如果回复了ACK，该重传定时时间失效，即不用重传了。如果没有回复ACK，定时器的时间又到了，就开始重传。TCP会将数据拆分成段进行发送，出于效率和传输速度的考虑，不能一段一段将数据进行传送，因为此传输效率十分低下，所以要实现对数据的批量发送。
3）、Tcp必须要解决可靠传输以及包乱序的问题，所以TCP需要知道网络实际处理数据的带宽，数据处理速度，这样才不会引起网络拥塞，导致丢包情况发生。
4）、TCP使用滑动窗口做流量控制与乱序重排。TCP的滑动窗口主要有两个作用，保证TCP的可靠性，保证TCP的流控特性。
13、HTTP超文本传输协议（基于请求与响应模式的无状态的应用层协议，常基于TCP的连接方式），HTTP1.1版本中给出一种持续连接的机制keep-alive，绝大多数web开发都是构建在http上面的web应用。注意，TCP是传输层协议，HTTP是应用层协议，HTTP是基于TCP协议的一种连接方式。主要特点，如下所示：
1）、特点一、支持客户端和服务器端模式。HTTP协议工作于客户端和服务器端架构之上的，浏览器作为HTTP客户端通过URL向HTTP服务器端即web服务器发送所有请求。WEB服务器根据接收到的请求向客户端发送响应信息。
2）、特点二、简单快速。客户端向服务器端请求服务的时候，只需要传送请求方法和请求路径，请求方法常用的有GET、POST、PUT、DELETE等等，每种方法规定了客户端与服务器连接的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
3）、特点三、灵活。HTTP允许传输任意类型的数据对象。正在传输的对象由context type加以标记。
4）、特点四、无连接。无连接的含义是限制每次连接只处理一个请求，服务器处理完客户的请求，并收到客户的应答以后即断开连接。采用该方式节省传输时间。从HTTP1.1起，默认使用了长连接，即服务器需要等待一定时间后才断开连接，以保证连接特性。虽然目前的技术，如keep alive使用了长连接优化效率，但是这些都是属于HTTP请求之外的，也即在每个独立的http请求中，你是无法知道当前的http是否处于长连接的状态，你始终会认为http请求在处理结束以后连接就会关闭，这是http的特性。长连接可以认为是下层实现对上层透明。
5）、特点五、无状态。http协议是无状态协议，无状态是指协议对事物处理没有记忆能力，缺少状态意味着如果后续处理需要前段信息则必须被重新传输，这样可能会导致每次连接传送的数据量增大。另一方面在服务器不需要先前信息的时候，它的应答就较快。HTTP协议目前处于多个版本共存的情况（HTTP1.0版本，HTTP1.1版本，HTTP2.0版本）。HTTP1.1版本相对于HTTP1.0版本引入了keep alive长连接技术。
14、HTTP的请求结构（HTTP请求报文），主要包含请求行、请求头部、空行、请求正文四部分组成。
1）、请求行包含三个部分（请求方法、URL路径、协议版本），请求方法、空格、URL路径、空格、协议版本、回车符、换行符。
2）、请求头部有若干个报头组成，每个报头包含，头部字段名、分号、值、回车符、换行符。即使请求正文没有内容，也会空一行出来的。
15、HTTP的响应结构（HTTP响应报文），发送请求报文以后，正常情况下会收到响应报文。主要包含状态行、响应头部、空行、响应正文四部分组成。
16、HTTP的简介以及请求响应的步骤，如下所示：
1）、Http简介，http协议定义了web客户端如何从web服务器请求web页面，以及服务器如何把web页面传送给客户端，http协议采用了请求响应模型，客户端向服务器发送请求报文，请求报文包含了请求方法、URL、协议版本、请求头部、请求数据。服务器以一个状态行作为响应，响应的内容包含了协议的版本，成功或者失败的状态码，服务器信息，响应头部和响应数据。
2）、请求响应的步骤。
a）、客户端连接到web服务器，一个http客户端通常是浏览器与web服务器的http端口，默认端口号是80，建立一个tcp套接字连接。
b）、然后发送http请求，即通过tcp套接字，客户端向web服务器发送一个文本的请求报文。
c）、然后服务器接受到客户端的请求并返回HTTP响应。web服务器解析该请求定位请求资源，服务器将资源副本写到tcp套接字由客户端读取。
d）、然后释放TCP连接。若连接模式是CLOSE，则服务器主动关闭tcp连接，客户端被动关闭tcp连接，释放tcp连接。若连接模式是keep alive，咋该连接会保持一段时间，在该时间内可以继续接受请求。
e）、然后客户端浏览器解析HTML内容。并进行解析，客户端浏览器首先解析状态行，查看表名请求是否成功的状态代码，然后解析每一个响应头，响应头告知以下若干字节的HTML文档和文档的字符集，客户端浏览器读取响应数据HTML，根据html语法对其进行格式化，并在浏览器窗口中进行解释。
17、在浏览器地址栏键入URL，按下回车以后经历的流程，如下所示：
a）、DNS解析，浏览器会根据URL逐层查询DNS服务器缓存，解析URL中的域名所对应的IP地址。DNS缓存从近到远依次是浏览器缓存、系统缓存、路由器缓存、ips服务器缓存、根域名服务器缓存、*域名服务器缓存。从那个缓存找到对应的ip以后直接返回，不再查询后面的缓存。
b）、TCP连接。找到ip地址以后会根据ip地址和默认端口80，和服务器建立tcp连接。该步骤即是三次握手了。
c）、发送HTTP请求。此时浏览器会发送读取文件的http请求，该请求将发送给服务器。
d）、服务器处理请求并返回HTTP报文。服务器对浏览器请求做出响应并把对应的带有html文本的http响应报文发送给浏览器。
e）、浏览器解析渲染页面。然后浏览器收到html并在显示窗口内进行渲染。
f）、连接结束。最后浏览器是否了TCP连接。该步骤即是四次挥手。
18、HTTP状态码，五种可能的取值。
a）、1xx，指示信息，表示请求已接收，继续处理。
b）、2xx，成功，表示请求已被成功接收、理解、接受。
c）、3xx，重定向，要完成请求必须进行更进一步的操作。
d）、4xx，客户端错误，请求有语法错误或者请求无法实现。
e）、5xx，服务器端错误，服务器未能实现合法的请求。
19、常见HTTP状态码。如下所示：
20、GET请求和POST请求的区别，从三个层面来进行解答。如下所示：
1）、第一点区别：Http报文层面，GET将请求信息放到URL，请求信息与URL之间使用问号隔开，请求信息格式是键值对的形式，POST将请求信息放在报文体中，获取请求信息必须解析报文。GET请求是放在URL中的，URL本身是没有长度限制的，但是浏览器是有长度限制的，会对URL进行长度限制。POST是将请求信息放到报文体中的，所以对URL是没有长度限制的。
2）、第二点区别：数据库层面，GET符合幂等性（对数据库的一次操作或者多次操作的结果是一致的，则认为符合幂等性）和安全性（对数据库的操作没有改变数据库的数据，则认为符合安全性的，GET操作是做查询操作的，因此不会改变数据库里面的数据），POST不符合（POST请求既不幂等也不安全，POST会向数据库中提交数据，所以会改变数据库里面的数据，POST每次获取到的结果都有可能不一样的，因为POST请求是作用在上一级的URL上面的，每一次请求都会添加新资源）。
3）、第三点区别：GET请求可以被缓存（可以保存到浏览器的浏览记录中），被存储（GET请求URL可以被保存为浏览器书签），但是POST不行。
21、Cookie和Session的区别，如下所示：
1）、因为HTTP是无状态的，意味着每次访问有登录页面的需求的时候，都要输入账号和密码。Cookie技术是客户端的解决方案，是由服务器发送给客户端的特殊信息，以文本的形式存放在客户端。客户端每次向服务器发送请求的时候都会带上这些特殊信息，比如当客户使用浏览器访问支持Cookie的网站的时候，需要输入账号和密码提到到服务器，服务器向客户端回应超文本的同时将个人信息返回，个人信息不是存放在响应体http body中，而是保存到HTTP响应头http header中的，当客户端接收服务器的响应以后，浏览器将这些信息存放到统一位置。客户端再次请求的时候，会把Cookie发送到服务器中，Cookie信息存放到http响应头中。服务器接收到客户端浏览器的请求以后，会分析存放在请求头中的Cookie信息，得到客户端特有的信息，从而动态生成与该客户端相对应的内容。会解析Cookie生成与客户端相对应的内容。
2）、Cookie的设置以及发送过程，第一步，客户端发送Http Requert请求到服务器。第二步，服务器端发送Http Response和设置Cookie头部到客户端。第三步，客户端Http Request和Cookie头部请求到服务器端。第四步，服务器端发送一个Http Response请求到客户端。
3）、Session机制是一种服务器端的机制，在服务器上保存的信息。当程序需要为某个客户端的请求创建一个Session的时候，服务器首先检查这个请求里面是否已经包含session标识session id，如果包含了session id，说明之前为此客户端创建该Session，服务器根据Session id把这个session检索出来使用，如果检索不到，可能会新建一个Session，如果客户端请求不包含Session id，则为此客户端创建一个Session并生成一个与此Session相关的Session id（此Session id是不会重复且无规律的字符串）。
4）、Session的实现方式，主要有两种。第一种是使用Cookie进行实现。客户端发送请求，服务器给每个Session分配一个唯一的jsession id，并通过Cookie发送给客户端，当客户端发起新的请求的时候，将在Cookie头中携带这个jsession id，服务器可以查到对应的Session。第二种方式是使用URL回写来实现。服务器在发送给浏览器页面的所有链接中都携带jsession id参数，这样客户端点击任何一个链接，都会将jsession id带回服务器。如果直接在浏览器输入服务端资源的URL来请求该资源，session是匹配不到的，tomcat对session的实现是一开始同时是使用cookie和url回写机制，如果发现客户端支持cookie，就继续使用cookie，停止使用url回写机制，如果发现cookie被禁用，就一直使用url会写机制。
22、HTTP与HTTPS的区别。
1）、HTTP（Hyper Text Transfer Protocol）是超文本传输协议，HTTPS（Hyper Text Transfer Protocol Secure）是超文本传输安全协议。HTTPS是一种以计算机网络安全通信为目的的传输协议。HTTP是包含了ip、tcp、http，而HTTPS比HTTP新增了SSL或者TLS（具有保护交换数据隐私，以及完整性，提供对网上服务器身份认证的功能，是安全版的http）。
2）、SSL(Securiy Sockets Layer，安全套接层)，为网络通信提供安全以及数据完整性的一种安全协议，SSL位于TCP与各应用层之间，是操作系统对外的API，SSL3.0以后更名为TLS。采用身份验证和数据加密保证网络通信的安全和数据的完整性。
3）、Https采用了证书和加密手段的方式保证数据的安全性。Https数据传输流程，Https在数据传输之前，会与网站服务器和web浏览器进行一次握手，在握手的时候确认双方的加密密码信息。具体流程如下所示。
a、web浏览器将支持的加密算法信息发送给网站服务器。
b、服务器选择一套浏览器支持的加密算法，将验证身份的信息以证书的形式回发浏览器。
c、浏览器收到证书以后验证证书的合法性，如果证书受到浏览器信任，在浏览器地址栏有标志显示，否则显示不受信的标识。当证书受信以后，web浏览器随机生成一串密码，并使用证书中的公钥加密，之后使用约定好的hash算法握手消息b并生成随机数对消息进行加密，并将之前生成的信息回发给服务器。
d、服务器接收到web浏览器发送的消息以后，服务器使用私钥解密信息确认密码，然后通过密码解密web浏览器发送过来的握手信息，并验证哈希是否和web浏览器一致，加密新的握手响应消息回发浏览器。
e、web浏览器解密服务器经过哈希算法加密的握手响应消息，并对消息进行验真，如果和服务器发送过来的消息一致，则此握手过程结束以后，服务器和浏览器会使用之前浏览器生成的随机密码和对称密码进行加密，然后交换数据。
4）、HTTP与HTTPS的区别面试回答点。
区别一、HTTPS需要到CA申请证书，HTTP不需要。
区别二、HTTPS（Hyper Text Transfer Protocol Secure）是超文本加密传输协议，具有安全性的SSL加密传输协议，是密文传输，HTTP（Hyper Text Transfer Protocol）是超文本传输协议，是明文传输。
区别三、连接方式的不同，端口的不同，HTTPS默认使用的端口是443端口，HTTP默认使用的端口是80端口。
区别四、HTTPS=HTTP+加密+认证+完整性保护，SSL是有状态的，而HTTP连接是无状态的。
23、什么是Scoket呢？
Socket是对TCP/IP协议的抽象，是操作系统对外开发的接口。Socket是基于从打开，到读或者写，再到关闭的模式。
两个进程之间如果需要通信，最基本的一个前提是能够唯一的标识一个进程，在本地进程通信中我们可以使用pid来唯一标识一个进程，但是pid只是在本地唯一，网络中两个进程pid冲突的可能性还是存在的，这个时候需要再想它法。ip层的ip地址可以唯一标识一台主机，而tcp协议和端口号可以唯一标识主机的一个进程，这样我们可以利用ip地址加协议加端口号来唯一标识网络中的一个进程。当可以唯一标识网络中一个进程以后，我们就可以利用socket进行通信了。
24、Socket通信流程。
作者：别先生
博客园：https://www.cnblogs.com/biehongli/
如果您想及时得到个人撰写文章以及著作的消息推送，可以扫描上方二维码，关注个人公众号哦。
