7层，从上到下：应用层、表示层、会话层、运输层、网络层、数据链路层、物理层

5层，从上到下：应用层、运输层、网络层、数据链路层、物理层

TCP/IP4层，从上到下：应用层、运输层、网络层、网络接口层

常见协议

应用层：常见协议：
- FTP(21端口)：文件传输协议
- SSH(22端口)：远程登陆
- TELNET(23端口)：远程登录
- SMTP(25端口)：发送邮件
- POP3(110端口)：接收邮件
- HTTP(80端口)：超文本传输协议
- DNS(53端口)：运行在UDP上，域名解析服务
传输层：TCP/UDP
网络层：IP、ARP、NAT、RIP...
数据链路层：MAC：MAC是物理地址

三次握手、四次挥手

三次握手

第一次握手：Client将SYN置1，随机产生一个初始序列号seq发送给Server，进入SYN_SENT状态；
第二次握手：Server收到Client的SYN=1之后，知道客户端请求建立连接，将自己的SYN置1，ACK置1，产生一个acknowledge number=sequence number+1，并随机产生一个自己的初始序列号，发送给客户端；进入SYN_RCVD状态；
第三次握手：客户端检查acknowledge number是否为序列号+1，ACK是否为1，检查正确之后将自己的ACK置为1，产生一个acknowledge number=服务器发的序列号+1，发送给服务器；进入ESTABLISHED状态；服务器检查ACK为1和acknowledge number为序列号+1之后，也进入ESTABLISHED状态；完成三次握手，连接建立。

TCP建立连接可以两次握手吗？为什么?

不可以。有两个原因：

首先，可能会出现已失效的连接请求报文段又传到了服务器端。

其次，两次握手无法保证Client正确接收第二次握手的报文（Server无法确认Client是否收到），也无法保证Client和Server之间成功互换初始序列号。

可以采用四次握手吗？为什么？

可以。但是会降低传输的效率。

四次握手是指：第二次握手：Server只发送ACK和acknowledge number；而Server的SYN和初始序列号在第三次握手时发送；原来协议中的第三次握手变为第四次握手。出于优化目的，四次握手中的二、三可以合并。

第三次握手中，如果客户端的ACK未送达服务器，会怎样？

Server端：
由于Server没有收到ACK确认，因此会重发之前的SYN+ACK（默认重发五次，之后自动关闭连接进入CLOSED状态），Client收到后会重新传ACK给Server。
Client端，两种情况：
在Server进行超时重发的过程中，如果Client向服务器发送数据，数据头部的ACK是为1的，所以服务器收到数据之后会读取 ACK number，进入 establish 状态在Server进入CLOSED状态之后，如果Client向服务器发送数据，服务器会以RST包应答。

如果已经建立了连接，但客户端出现了故障怎么办？

服务器每收到一次客户端的请求后都会重新复位一个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

四次挥手

第一次挥手：Client将FIN置为1，发送一个序列号seq给Server；进入FIN_WAIT_1状态；
第二次挥手：Server收到FIN之后，发送一个ACK=1，acknowledge number=收到的序列号+1；进入CLOSE_WAIT状态。此时客户端已经没有要发送的数据了，但仍可以接受服务器发来的数据。
第三次挥手：Server将FIN置1，发送一个序列号给Client；进入LAST_ACK状态；
第四次挥手：Client收到服务器的FIN后，进入TIME_WAIT状态；接着将ACK置1，发送一个acknowledge number=序列号+1给服务器；服务器收到后，确认acknowledge number后，变为CLOSED状态，不再向客户端发送数据。客户端等待2*MSL（报文段最长寿命）时间后，也进入CLOSED状态。完成四次挥手。

为什么不能把服务器发送的ACK和FIN合并起来，变成三次挥手（CLOSE_WAIT状态意义是什么）？

因为服务器收到客户端断开连接的请求时，可能还有一些数据没有发完，这时先回复ACK，表示接收到了断开连接的请求。等到数据发完之后再发FIN，断开服务器到客户端的数据传送。

如果第二次挥手时服务器的ACK没有送达客户端，会怎样？

客户端没有收到ACK确认，会重新发送FIN请求。

客户端TIME_WAIT状态的意义是什么？

第四次挥手时，客户端发送给服务器的ACK有可能丢失，TIME_WAIT状态就是用来重发可能丢失的ACK报文。如果Server没有收到ACK，就会重发FIN，如果Client在2*MSL的时间内收到了FIN，就会重新发送ACK并再次等待2MSL，防止Server没有收到ACK而不断重发FIN。

MSL(Maximum Segment Lifetime)，指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

TCP如何实现流量控制？

使用滑动窗口协议实现流量控制。防止发送方发送速率太快，接收方缓存区不够导致溢出。

什么是零窗口（接收窗口为0时会怎样）？

如果接收方没有能力接收数据，就会将接收窗口设置为0，这时发送方必须暂停发送数据，但是会启动一个持续计时器(persistence timer)，到期后发送一个大小为1字节的探测数据包，以查看接收窗口状态。如果接收方能够接收数据，就会在返回的报文中更新接收窗口大小，恢复数据传送。

TCP的拥塞控制是怎么实现的？

什么是拥塞控制

拥塞就是接收方来不及处理发送方的数据，导致网络中的路由器或链路过载。拥塞控制是发生拥塞时如何解决。

拥塞控制主要由四个算法组成：慢启动、拥塞避免、快重传、快恢复

慢启动：刚开始发送数据时，拥塞窗口大小呈指数增加，达到门限值之后进入拥塞避免阶段；
拥塞避免：当拥塞窗口的大小达到慢开始门限时，开始执行拥塞避免算法，拥塞窗口大小不再指数增加，而是线性增加；
- 在慢启动或者拥塞避免阶段只要发送方没有收到确认就认为拥塞了，就要把慢开始门限值设置为当前值的一半，然后拥塞窗口设为1，重新执行慢开始+拥塞避免
快重传就是接收方发现数据丢失后，立即发送重复确认，当发送方连续收到三个重复确认时，立即重新重传丢失的数据
快恢复就是发送方连续收到三个重复确认时，把门限减半，此时不执行慢开始算法，而是将拥塞窗口大小设为门限的大小，然后执行拥塞避免算法

TCP与UDP的区别

TCP是面向连接的，UDP是无连接的；

什么叫无连接？

UDP发送数据之前不需要建立连接

TCP是可靠的，UDP不可靠；

什么是不可靠？

UDP接收方收到报文后，不需要给出任何确认

TCP只支持点对点通信，UDP支持一对一、一对多、多对一、多对多；
TCP是面向字节流的，UDP是面向报文的；

什么意思？

面向字节流是指发送数据时以字节为单位，一个数据包可以拆分成若干组进行发送，而UDP一个报文只能一次发完。 - TCP有拥塞控制机制，UDP没有。 - TCP首部开销（20字节）比UDP首部开销（8字节）要大 - UDP 的主机不需要维持复杂的连接状态表

什么时候选择TCP，什么时候选UDP？

对某些实时性要求比较高的情况，选择UDP，比如游戏，媒体通信，实时视频流（直播），即使出现传输错误也可以容忍；其它大部分情况下，HTTP都是用TCP，因为要求传输的内容可靠，不出现丢失

HTTP可以使用UDP吗？

HTTP不可以使用UDP，HTTP需要基于可靠的传输协议，而UDP不可靠

TCP如何保证可靠传输？

数据包校验:数据会被分割成TCP认为最适合发送的数据包、然后对每一个包进行编号，接收方接收后会按照序号拼接，检验和可以检测数据传输过程中的任何变化，如果发生变化就丢弃该报文段。同时TCP接收端也会主动丢弃掉重复的数据。
应答机制：接收方收到数据之后，会发送一个确认（通常延迟几分之一秒）
超时重发：发送方发出数据之后，启动一个定时器，超时未收到接收方的确认，则重新发送这个数据；
流量控制：确保接收端能够接收发送方的数据而不会缓冲区溢出
拥塞控制：解决数据传输拥塞问题

TCP超时重传中 RTT和RTO

RTT(Round Trip Time) 一个连接的往返时间，即数据发送时刻到接收到确认的时刻的差值；

RTO（Retransmission TimeOut）即重传超时时间。即从数据发送时刻算起，超过这个时间便执行重传。

由于网络波动的不确定性，每个RTT都是动态变化的，所以RTO也应随着RTT动态变化

https的连接过程？

客户端向服务器发送请求，同时发送客户端支持的一套加密规则（包括对称加密、非对称加密、摘要算法）；
服务器从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥（用于非对称加密），以及证书的颁发机构等信息（证书中的私钥只能用于服务器端进行解密）；
客户端验证服务器的合法性，包括：证书是否过期，CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配；
如果证书受信任，或者用户接收了不受信任的证书，浏览器会生成一个随机密钥（用于对称算法），并用服务器提供的公钥加密（采用非对称算法对密钥加密）；使用Hash算法对握手消息进行摘要计算，并对摘要使用之前产生的密钥加密（对称算法）；将加密后的随机密钥和摘要一起发送给服务器；
服务器使用自己的私钥解密，得到对称加密的密钥，用这个密钥解密出Hash摘要值，并验证握手消息是否一致；如果一致，服务器使用对称加密的密钥加密握手消息发给浏览器；
浏览器解密并验证摘要，若一致，则握手结束。之后的数据传送都使用对称加密的密钥进行加密

总结：非对称加密算法用于在握手过程中加密生成的密码；对称加密算法用于对真正传输的数据进行加密；HASH算法用于验证数据的完整性。

输入 www.baidu.com，怎么变成 https://www.baidu.com 的，怎么确定用HTTP还是HTTPS？

一种是原始的302跳转，服务器把所有的HTTp流量跳转到HTTPS。但这样有一个漏洞，就是中间人可能在第一次访问站点的时候就劫持。解决方法是引入HSTS机制，用户浏览器在访问站点的时候强制使用HTTPS。

什么是对称加密、非对称加密？区别是什么？

对称加密：加密和解密采用相同的密钥。如：DES、RC2、RC4- 非对称加密：需要两个密钥：公钥和私钥。如果用公钥加密，需要用私钥才能解密。如：RSA
区别：对称加密速度更快，通常用于大量数据的加密；非对称加密安全性更高（不需要传送私钥）

细说：对称密钥加密是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方；而非对称加密是指使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。

GET与POST的区别？

GET是幂等的，即读取同一个资源，总是得到相同的数据，POST不是幂等的；
GET一般用于从服务器获取资源，而POST有可能改变服务器上的资源；
请求形式上：GET请求的数据附在URL之后，在HTTP请求头中；POST请求的数据在请求体中；
安全性：GET请求可被缓存、收藏、保留到历史记录，且其请求数据明文出现在URL中。POST的参数不会被保存，安全性相对较高；
GET只允许ASCII字符，POST对数据类型没有要求，也允许二进制数据；
GET的长度有限制（操作系统或者浏览器），而POST数据大小无限制

Session与Cookie的区别？

Session是服务器端保持状态的方案，Cookie是客户端保持状态的方案

Cookie保存在客户端本地，客户端请求服务器时会将Cookie一起提交；Session保存在服务端，通过检索Sessionid查看状态。保存Sessionid的方式可以采用Cookie，如果禁用了Cookie，可以使用URL重写机制（把会话ID保存在URL中）。

HTTP请求有哪些常见状态码？

2xx状态码：操作成功。200 OK 3xx状态码：重定向。301 永久重定向；302暂时重定向 4xx状态码：客户端错误。400 Bad Request；401 Unauthorized；403 Forbidden；404 Not Found； 5xx状态码：服务端错误。500服务器内部错误；501服务不可用

各种协议和HTTP协议之间的关系

首先发给DNS服务器，进行域名解析，得到IP地址后生成针对目标Web服务器的HTTP请求报文，然后报文由TCP协议负责传输，为了方便通信，HTTP请求报文被分为报文段，然后每个报文段可靠的传输给对方，然后报文段由IP层负责一边中转一遍传送，服务器收到报文段后重组报文段，然后由应用层的HTTP协议处理请求的内容，请求的结果以同样的方式进行回传。

客户端不断进行请求链接会怎样？DDos(Distributed Denial of Service)攻击？

服务器端会为每个请求创建一个链接，并向其发送确认报文，然后等待客户端进行确认

1)、DDos 攻击

客户端向服务端发送请求链接数据包
服务端向客户端发送确认数据包
客户端不向服务端发送确认数据包，服务器一直等待来自客户端的确认

2)、DDos 预防 ( 没有彻底根治的办法，除非不使用TCP )

限制同时打开SYN半链接的数目
缩短SYN半链接的Time out 时间
关闭不必要的服务

SQL 注入

SQL注入就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。

SQL注入攻击的总体思路

(1). 寻找到SQL注入的位置
(2). 判断服务器类型和后台数据库类型
(3). 针对不通的服务器和数据库特点进行SQL注入攻击

在浏览器中输入url地址到显示主页的过程

1.浏览器查找域名的IP地址，这时要使用DNS解析 2.浏览器和服务器建立TCP连接，这时要使用TCP和IP协议 3.IP数据包在路由器之间传输需要使用OSPF协议进行路由选择 4.路由器与服务器通信时，要将ip地址转成MAC地址，需要使用ARP协议 5.浏览器向服务器发送HTTP请求，这时需要使用HTTP协议 6.服务器处理请求 7.服务器返回一个HTML响应 8.浏览器开始显示HTML

HTTP长连接、短连接

HTTP/1.0中默认使用短连接，客户端和服务器每进行一次HTTP操作就要进行一次连接，如果访问的HTTP资源中包含其他Web资源，对于每一个这样的资源都要去重新建立一个HTTP会话。
HTTP1.1以上默认使用长连接，一个网页打开后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。
- 长连接不会永久保持，有一个保持时间

HTTP1.0和HTTP1.1的区别

HTTP1.1默认使用长连接 HTTP1.1新增了一些错误状态码 HTTP1.1引入了更多的缓存控制策略 HTTP1.1进行了一些带宽的优化

HTTP是不保存状态的协议，那如何保存用户状态？

HTTP是无状态协议，Session可以通过服务端来记录用户状态。

但注意要实现Session跟踪，这一般通过Cookie中附带一个SessionID实现

如果禁用了Cookie，可以利用URL重写把SesssionID直接附加到URL后面。

HTTP和HTTPS区别？

HTTP运行于TCP之上，明文传输，客户端和服务器都无法验证对方的身份；HTTPS运行于SSL之上，SSL运行于TCP之上，是添加了加密和认证机制的HTTP
HTTP使用80端口，HTTPS使用443端口
HTTPS消耗更多资源，而且需要证书，证书需要购买