TCP/IP协议、HTTP协议
面试时，我们可能会被问到TCP/IP相关问题，比如：
- 什么是TCP/IP协议？
- TCP建立连接为什么要进行三次握手？
- TCP断开连接为什么要进行四次挥手？
一、TCP/IP协议模型
（TCP协议）传输控制协议是一种面向连接的、可靠的、基于字节流的方式进行有序的无差错的数据传输通讯协议，它负责完成传输层所指定的功能，利用重发技术和拥塞控制机制，向应用程序提供可靠的通信连接，使它能够自动适应网上的各种变化。比如：数据报检测、流量控制、拥塞控制、数据排序、超时重发等
1.1 网络分层模型
OSI：Open System Interconnection， 开放式系统互联国际标准化组织(ISO)制定的理论模型。
各层含义：
应用层：是为计算机用户提供应用接口，也为用户直接提供各种网络服务。我们常见应用层的网络服务协议有：HTTP，HTTPS，FTP，POP3、SMTP等。
表示层：提供各种用于应用层数据的编码和转换功能,确保一个系统的应用层发送的数据能被另一个系统的应用层识别。
会话层：就是负责建立、管理和终止表示层实体之间的通信会话。该层的通信由不同设备中的应用程序之间的服务请求和响应组成。
传输层：传输层建立了主机端到端的链接，传输层的作用是为上层协议提供端到端的可靠和透明的数据传输服务。
网络层：本层通过IP寻址来建立两个节点之间的连接，为源端的运输层送来的分组，选择合适的路由和交换节点，正确无误地按照地址传送给目的端的运输层。就是通常说的IP层。这一层就是我们经常说的IP协议层。
数据链路层：将比特组合成字节,再将字节组合成帧,使用链路层地址 (以太网使用MAC地址)来访问介质,并进行差错检测。
理层： 实际最终信号的传输是通过物理层实现的。通过物理介质传输比特流。
1.2 TCP报文中的字段
序号(sequencenumber)：用来标识从源端到目的端发送的字节流，发起方发送数据时对此进行标记，比如：一个报文段的序号为100，此报文段数据部分共有200字节，则下一个报文段序号为300
确认号(acknowledgement number)：指明下一个期待收到的字节序号，只有ACK标志位为1时确认序号字段才有效，ack = seq+1
1.3 标志位：
① URG：紧急指针标志，为1时表示紧急指针有效
② ACK：确认序号标志，ACK=1 时表示有效。只有当 ACK=1 时，前面的确认号字段才有效，TCP连接建立后，ACK 必须为 1
③ PSH：表示接收方在收到该报文段后应尽快将该报文段交给应用程序
④ RST：当RST=1时说明 TCP 连接出现了错误(如主机崩溃)，必须释放连接后再重新建立连接，或者用于拒绝非法的报文段和拒绝连接请求
⑤ SYN：发起新连接，当SYN=1，表示这是一个请求建立连接的报文段；当SYN=1，ACK=1时，表示对方同意建立连接，只有在前两次握手中 SYN 才为 1
⑥ FIN：用于释放连接，FIN=1表示数据已经发送完成，可以释放连接
1.4 TCP三次握手
在TCP建立连接的过程中，必定由一方主动发起，另一方被动接收，下图为客户端主动发起的图解：
首先主动打开连接的客户端结束CLOSED状态，被动打开的服务器端也结束CLOSED状态，并进入LISTEN状态。随后开始“三次握手”：
① 客户端向服务端发送一段TCP报文：
标志位为SYN=1，表示“请求建立新连接”；序号为seq=x（x通常为1）；随后客户端进入SYN-SENT状态
②服务端接收到来自客户端的TCP报文之后，结束LISTEN状态，并返回一段TCP报文：
标志位为SYN=1，ACK=1，表示“已收到请求并同意创建新连接”；序号为seq=y；确认号为ack=x+1，表示将来自客户端的报文序号seq值加1作为自己确认号ack的值；随后服务端进入SYN-RCVD状态
③客户端收到服务端的同意连接TCP报文后，确认了双方间数据传输是正常的，结束SYN-SENT状态，并返回最后一段TCP报文：
标志位为ACK=1，表示“已收到同意连接的信号”；序号为seq=x+1，表示将来自服务端的确认号ack值作为自己的序号值；确认号为ack=y+1，表示将来自服务端序号seq值加1作为自己的确认号ack的值；随后客户端进入ESTABLISHED状态
服务端收到来自客户端的确认连接TCP报文之后，也确认了双方间数据传输正常，结束SYN-RCVD状态，进入ESTABLISHED状态
在第三次握手时就可以携带数据了，因为能够发出第三次握手报文的客户端，肯定接收到来自服务端的第二次握手报文，而伪造IP的客户端是不会接收到第二次报文的，所以，能够发出第三次握手报文的就是合法的用户，服务端在接收到第三次握手的瞬间，状态就会切换为ESTABLISHED，里面携带的数据就可以按照正常流程走了
为何两次握手不可以呢？原因是为了防止服务端开启一些无用的连接增加服务器开销以及防止已失效的连接请求报文段突然又传送到了服务端而产生错误。“第三次握手”是客户端向服务端发送数据，目的是告诉服务器，客户端有没有收到服务器“第二次握手”时传过去的数据，若发送的是“收到了”的信号，服务端接收后就正常建立TCP连接，否则建立TCP连接失败，服务器关闭连接端口，由此减少服务器开销及防止接收到失效请求而导致错误
为什么是三次握手？首先要明确下TCP握手的目的是为了通信，能够完成数据传输。那么通信的前提就是客户端和服务端都要具备读写能力。
服务端收到客户端发来的请求(即第一次握手)能够证明客户端具备写的能力，接下来服务端给客户端进行回复信息（即第二次握手），客户端收到服务端回复的信息能够证明服务端具备读写的能力；客户端发送给服务端最后一段报文（即第三次握手），服务端收到后能够证明客户端具备读的能力。
1.5 TCP四次挥手
所谓四次挥手就是TCP连接断开的过程，下图为客户端主动发起断开连接的图解：
挥手之前主动释放连接的客户端结束ESTABLISHED状态，随后开始“四次挥手”：
①客户端向服务端发送TCP报文：
标志位为FIN=1，表示“请求释放连接”，序列号为seq=u，随后客户端进入FIN-WAIT-1状态并停止向服务端发送数据
②服务端收到从客户端发出的释放连接的TCP报文后结束ESTABLISHED状态，进入CLOSE-WAIT状态并返回一段TCP报文：
标志位为ACK=1，表示“收到释放请求”，序列号为seq=v，确认号ack=u+1，表示将来自客户端报文序号seq值加1作为自己的确认号ack的值，随后服务端进入CLOSE-WAIT状态
③客户端收到服务端确认结果后，进入FIN-WAIT-2状态。服务端做好了释放连接准备后再次向客户端发出一段TCP报文：
标志位为FIN=1，ACK=1，表示“已准备好释放”，序号为seq=w，确认号ack=u+1，服务器进入LAST-ACK状态并停止向客户端发送数据
④客户端收到回复后，结束FIN-WAIT-2状态，进入TIME-WAIT状态，并向服务端发送一段报文：
标志位为ACK=1，表示“已收到准备释放信号”，序列号为seq=u+1，确认号为ack=w+1，表示将来自服务端报文序号seq值加1作为自己的确认号ack的值，客户端进入TIME-WAIT状态，客户端经过2MSL后进入CLOSE状态；服务器收到确认后，立刻进入CLOSE状态
（MSL指的是Maximum Segment Lifetime：一段TCP报文在传输过程中的最大生命周期。2MSL即是服务端发出为FIN报文和客户端发出的ACK确认报文所能保持有效的最大时长）
为什么是四次挥手？客户端要断开连接，会给服务端发送一段FIN报文（第一次挥手），此时服务端会立刻响应回复给客户端一段报文（第二次挥手），表示服务端收到了客户端的断开请求，不会再有数据发送过来了，但这时客户端仍然可以收到服务端发过来的数据。因为服务端的数据可能还没有发送完毕。等到服务端数据全部发送完成后，才会发送自己的一段FIN报文给客户端（第三次挥手），表示服务端也准备断开连接了，不会再有数据发送。客户端收到服务端的断开请求，会响应一段报文给服务端（第四次挥手），最后双方都断开了连接。
1.6 TCP连接状态解释
| 字段 | 含义 |
|---|---|
| CLOSED | 关闭状态，表示当前主机没有正在运行的传输连接 |
| LISTEN | 监听状态，表示服务器正在等待新的传输连接进入 |
| SYN-RCVD | 表示主机已收到一个连接请求，但尚未确认 |
| SYN-SENT | 表示主机已经发出一个连接请求，等待对方确认 |
| ESTABLISHED | 传输连接建立，双方进入正常数据传输状态 |
| FIN-WAIT-1 | （主动关闭）主机已经发送关闭连接请求，等待对方确认 |
| FIN-WAIT-2 | （主动关闭）主机已收到对方关闭连接确认，等待对方发送关闭连接请求 |
| TIMED WAIT | 完成双向传输连接关闭，等待所有分组消失 |
| CLOSING | 双方同时尝试关闭传输连接，等待对方确认 |
| CLOSE WAIT | （被动关闭）收到对方发来的关闭连接请求，并已确认 |
| LAST ACK | 被动关闭）等待最后一个关闭连接确认，并等待所有分组消失 |
二、HTTP
HTTP协议是超文本传输协议（Hyper Text Transfer Protocol），是用于从万维网服务器传输超文本到本地浏览器的传送协议。
HTTP是一个基于TCP/IP通信协议来传递数据的。
主要特点：
- 支持客户/服务器模型
- 简单快速：客户端向服务器请求服务时，只需传输请求方法和路径，请求方法常用的有GET、POST、HEAD。每种方法规定了客户和服务器联系的类型不同，由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通讯速度很快。
- 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记
- 无连接：是指限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
- 无状态：是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
2.1 发展历程
HTTP0.9版本
- 请求方法支持有限
只支持GET请求方式，不支持其他请求方式 因此客户端向服务端传输信息的量非常有限，也就是现在常用的Post请求无法使用 - 不支持请求头header
不能在请求中指定版本号，服务端只具有返回HTML字符串的能力 - 响应即关闭
服务端相响应之后，立即关闭TCP连接
HTTP1.0版本
- 丰富请求方法
请求方式新增了POST，DELETE，PUT，HEADER等方式，提高了客户端向服务端发送信息的量级 - 增加请求头和响应头
增添了请求头和响应头的概念，可以在通信中指定了HTTP协议版本号，以及其他header信息，使得C/S交互更加灵活方便 - 丰富数据传输内容
扩充了传输内容格式包括：图片、音视频资源、二进制等都可以进行传输，相比0.9的只能传输html内容让http的应用场景更多 - 链接复用性差
1.0版本中每个TCP连接只能发送一个请求，数据发送完毕连接就关闭，如果还要请求其他资源，就必须重新建立连接。TCP为了保证正确性和可靠性需要客户端和服务器三次握手和四次挥手，因此建立连接成本很高，基于拥塞控制开始时发送速率较慢，所以1.0版本的性能并不理想。
无状态无连接的弊端
1.0版本是无状态且无连接的，换句话说就是服务器不跟踪不记录请求过的状态，客户端每次请求都需要建立tcp连接不能复用，并且1.0规定在前一个请求响应到达之后下一个请求才能发送，如果前一个阻塞后面的请求就会被阻塞。 丢包和乱序问题和高成本的链接过程让复用和队头阻塞产生很多问题，所以无连接无状态是1.0版本的一个弱肋。
HTTP1.1版本
- 增加长连接
新增Connection字段，可以设置keep-alive值保持连接不断开，即 TCP 连接默认不关闭，可以被多个请求复用，这也是1.1版本很重要的优化，但是在S端服务器只有处理完一个回应，才会进行下一个回应。要是前面的回应特别慢，后面就会有许多请求排队等着，仍然存在队头阻塞问题。 - 管道化
在长连接的基础上，管道化可以不等第一个请求响应继续发送后面的请求，但响应的顺序还是按照请求的顺序返回，即在同一个TCP连接中，客户端可以同时发送多个请求，进一步改进了HTTP协议的传输效率。 - 更多的请求方法
增加了 PUT、PATCH、OPTIONS、DELETE 等请求方式。 - host字段
Host字段用来指定服务器的域名，这样就可以将多种请求发往同一台服务器上的不同网站，提高了机器的复用，这个也是重要的优化
HTTP2.0版本
- 二进制格式
1.x是文本协议，然而2.0是以二进制帧为基本单位，可以说是一个二进制协议，将所有传输的信息分割为消息和帧，并采用二进制格式的编码，一帧中包含数据和标识符，使得网络传输变得高效而灵活。 - 多路复用
这是一个非常重要的改进，1.x中建立多个连接的消耗以及效率都存在问题，2.0版本的多路复用多个请求共用一个连接，多个请求可以同时在一个TCP连接上并发，主要借助于二进制帧中的标识进行区分实现链路的复用。 - 头部压缩
2.0版本使用使用HPACK算法对头部header数据进行压缩，从而减少请求的大小提高效率，这个非常好理解，之前每次发送都要带相同的header，显得很冗余，2.0版本对头部信息进行增量更新有效减少了头部数据的传输。 - 服务端推送
这个功能有点意思，之前1.x版本服务端都是收到请求后被动执行，在2.0版本允许服务器主动向客户端发送资源，这样在客户端可以起到加速的作用。
2.2 报文格式
2.2.1请求报文
下面是一个实际的请求报文：
2.2.2 响应报文
下面是一个实际的响应报文：
2.2.3 URL
URL叫统一资源定位符
以下面这个URL为例，介绍普通URL的各部分组成：
http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name
①、协议部分：即http
②、域名部分：即www.aspxfans.com
③、端口部分：即8080
④、虚拟目录部分：从域名后的第一个“/”开始到最后一个“/”为止，即/news/
⑤、文件名部分：从域名后的最后一个“/”开始到“？”为止，是文件名部分，如果没有“?”,则是从域名后的最后一个“/”开始到“#”为止，是文件部分，如果没有“？”和“#”，那么从域名后的最后一个“/”开始到结束，都是文件名部分。本例中的文件名是“index.asp”。
⑥、锚部分：从“#”开始到最后，都是锚部分。本例中的锚部分是“name”。
⑦、参数部分：从“？”开始到“#”为止之间的部分为参数部分。
URI和URL的区别
URI是统一资源标识符，用来唯一的标识一个资源。
URL是统一资源定位符，URL是URI的一个子集，它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何定位这个资源。
三、TCP/IP协议与Http协议的区别
TPC/IP协议是传输层协议，主要解决数据如何在网络中传输，而HTTP是应用层协议，主要解决如何包装数据。
我们把IP想象成一条高速公路，它允许其它协议在上面行驶并找到到其它电脑的出口。TCP和UDP是高速公路上的“卡车”，它们携带的货物就是像HTTP。
四、HTTP与socket的区别：
HTTP：超文本传输协议，首先它是一个协议，并且是基于TCP/IP协议基础之上的应用层协议。TCP/IP协议是传输层协议，主要解决数据如何在网络中传输，HTTP是应用层协议，主要解决如何包装数据。HTTP协议详细规定了浏览器与服务器之间相互通信的规则，是万维网交换信息的基础。HTTP是基于请求-响应形式并且是短连接，并且是无状态的协议。针对其无状态特性，在实际应用中又需要有状态的形式，因此一般会通过session/cookie技术来解决此问题。
Socket：Socket不属于协议范畴，而是一个调用接口（API），Socket是对TCP/IP协议的封装，通过调用Socket，才能使用TCP/IP协议。Socket连接是长连接，理论上客户端和服务器端一旦建立连接将不会主动断开此连接。Socket连接属于请求-响应形式，服务端可主动将消息推送给客户端。
五、HTTPS
5.1 概述
HTTP在传输数据时，所传输的内容都是明文，无法保证数据的安全性。HTTPS就是在安全的传输层上发送的HTTP。HTTPS没有将未加密的HTTP报文发送给TCP。并通过世界范围内的因特网进行传输，它在将HTTP报文发送给TCP之前，现将其发送给了一个安全层（通过SSL及现代替代协议TLS来实现的），对其进行加密。目的就是对数据信息进行加密。
SSL(Secure Sockets Layer 安全套接层)协议,及其继任者TLS（Transport Layer Security传输层安全）协议，是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层对网络连接进行加密，用于保障网络数据传输安全，利用数据加密技术，确保数据在网络传输过程中不会被截取及窃听。
注：TSL 1.0是建立在SSL3.0协议规范之上，是SSL3.0的后续版本，可以理解为SSL3.1
5.2 SSL握手
在发送已加密的HTTP报文之前，客户端和服务器要进行一次SSL握手，在这个握手过程中，它们要完成以下工作：
- 交换协议版本号
- 选择一个两端都了解的密码
- 对两端的身份进行认证
- 生成临时的会话密钥，以便加密信道
SSL握手的目的是什么？过程又是怎样的？
SSL握手的过程都是明文，因此SSL握手的重点就在于怎么在不安全的网络中安全的进行密钥交换。
RSA算法交换密钥步骤
①、客户端给出协议版本号、一个随机数（Random1),以及客户端支持的加密方法；
②、服务端确认使用的加密算法，并给出数字证书，以及随机数(Random2);
③、客户端确认数字证书有效，生成一个新的随机数（premaster secret)，并使用数字证书的公钥，利用RSA算法加密这个随机数。发给服务端。
④、服务端使用自己的私钥，获取客户端发来的随机数（premaster secret)。
⑤、客户端和服务端根据约定的加密方法，使用前面的三个随机数，生成对话密钥（master secret），用来加密接下来的整个对话过程。
六、HTTPS和HTTP的区别：
- HTTPS协议需要到ca申请证书，一般免费证书很少，需要交费。
- HTTP是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议
- HTTP和HTTPS使用的是完全不同的连接方式用的端口也不一样,前者是80,后者是443。
- HTTP的连接很简单,是无状态的
- HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议 要比http协议安全