OSI网络分层
| 分层 | OSI分层 | 该层协议 |
|---|---|---|
| 应用层 | 应用层 | http、ssh、smtp、pop、ssl/tls、ftp、mime、DNS |
| 表示层 | ||
| 会话层 | ||
| 传输层 | 传输层 | tcp、udp |
| 网络层 | 网络层 | ip4、ip6、ARP（解析地址、根据ip地址反查出对应MAC地址） |
| 链路层 | 数据链路层 | 以太网、网线、光纤 |
| 物理层 |
三次握手
握手过程中使用了TCP的标志（flag） SYN：synchronize ACK：acknowledgement
发送端->接收端：发送标有SYN的数据包
接收端->发送端：接收到数据包，发送标有SYN/ACK的数据包
发送端->接收端：收到数据包，发送标有ACK的数据包，握手结束
如果某个阶段莫名中断，TCP协议会再次握手
TCP的三次握手过程？为什么会采用三次握手，若采用二次握手可以吗？
答:建立连接的过程是利用客户服务器模式，假设主机A为客户端，主机B为服务器端。
（1）TCP的三次握手过程：主机A向B发送连接请求；主机B对收到的主机A的报文段进行确认；主机A再次对主机B的确认进行确认。
（2）采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。失效的连接请求报文段是指：主机A发出的连接请求没有收到主机B的确认，于是经过一段时间后，主机A又重新向主机B发送连接请求，且建立成功，顺序完成数据传输。考虑这样一种特殊情况，主机A第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机B，主机B以为是主机A又发起的新连接，于是主机B同意连接，并向主机A发回确认，但是此时主机A根本不会理会，主机B就一直在等待主机A发送数据，导致主机B的资源浪费。
（3）采用两次握手不行，原因就是上面说的实效的连接请求的特殊情况
四次挥手
A为客户端，B为服务端
为什么是四次呢？ TCP采用全双工模式
全双工模式：可以同时进行双向的数据传输，所以AB既是发送端又是接收端，所以每次断开连接，需要一个发送端发送FIN断开请求，接收端发送ACK确认断开请求，两个连接，四次挥手
第一次分手：A发送FIN报文段给B，用来断开客户端到服务端的连接，此时A处于FIN_WAIT_1状态，等待B断开连接的确认
第二次分手：B收到A的FIN报文段后，回传一个ACK报文段，同意客户端的断开请求，此时B进入CLOSE_WAIT状态，等待A关闭连接，A收到B的ACK后，A关闭向B发送数据的连接，A进入FIN_WAIT_2状态
第三次挥手：A到B的连接断开后，B发送FIN报文段给A，请求断开服务端到客户端的连接，B进入LAST_ACK状态，等待A断开连接的确认
第四次挥手：A收到B的FIN后，回传一个ACK，同意关闭连接，此时A进入TIME_WAIT状态，B收到A的ACK报文段后，关闭服务端向客户端发送数据的连接，B进入CLOSED状态，此时客户端还处于TIME_WAIT，等待两个MSL时间后，自动进入CLOSED状态
DNS服务
域名-解析->IP地址
发送端-域名->DNS DNS-IP->发送端 发送端-IP->对应IP地址的服务器
一次完整HTTP通信过程
客户端-域名->DNS
DNS-IP->客户端
HTTP协议的职责：生成对目标Web服务器的请求报文
TCP协议的职责：为了方便通信，将HTTP请求报文按序号分割成多个报文段，把每个报文段可靠度传给对方
IP协议的职责：搜索对方地址，一边中转一遍传送
TCP协议的职责：收到报文段后，按序号重组请求报文
HTTP协议的职责：解析客户端对Web服务器的请求的内容的处理
请求处理的结果也同样利用TCP/IP协议向客户端回传
HTTP协议报文
请求报文由请求方法、请求URI、协议版本、可选的请求首部字段、内容实体构成
1 2 3 4 5 6 7 8 9 10 |
POST(请求方法) /from(请求URI) HTTP/1.1(协议版本) Host:google.com Connection:keep-live Content-Type:application/x-www-form-urlencoded Content-Length:16 ... (请求首部字段) name=uers(内容实体) |
响应报文由协议版本、状态码、解释状态码的原因短语、可选的响应首部字段和实体主体构成
1 2 3 4 5 6 |
HTTP/1.1 200 OK Date:Tue, 10.. Content-Length:36 Content-Type:text/html <html>... |
Cookie
HTTP是无状态协议，不对发生过的请求和响应的状态进行管理，无法根据之前的状态进行本次的请求处理 由此产生的问题例如Web保存登录状态 Cookie技术通过在请求和响应报文（首部字段）中写入Cookie信息来控制客户端的状态
请求过程
A客户端 B服务器
没有cookie状态下 A-请求（无cookie）->B B（Set-Cookie）-响应（带Set-Cookie）->A(保存cookie)
有cookie状态下 A-请求（cookie）->B检查cookie B-响应（根据cookie）->A
状态码
| 类别 | 原因 | |
|---|---|---|
| 1XX | Information 信息性状态码 | 接收的请求正在处理 |
| 2XX | Success 成功状态码 | 请求正常处理完毕 |
| 3XX | Redirection 重定向状态码 | 需要进行附加操作以完成请求 |
| 4XX | Client Error 客户端错误状态码 | 服务器无法处理请求 |
| 5XX | Server Error 服务器错误状态码 | 服务器处理请求出错 |
常见状态码
- 200 OK 表示从客户端发来的请求在服务端被正常处理了
- 202 No Content 表示服务器成功处理了请求，但在返回响应报文中不含实体的主体部分，一般在只需要客户端往服务端发送信息时使用
- 204 Partial Cotent 表示客户端进行了范围请求，服务器成功执行了这部分的GET请求
- 301 Moved Permanently 永久性重定向，表示请求的资源已被分配新的URI，以后应使用新的URI
- 302 Found 临时性重定向 ，表示请求的资源已被分配新的URI，希望本次使用新的URI访问
- 303 See Other 表示由于请求对应的资源存在着另一个URI，应使用GET方法定向获取请求的资源
- 304 Not Modified 表示客户端发送附带条件（If-Match、If-Modified-Since等）的请求时，服务器允许请求访问资源，但是未满足条件，直接返回304（可直接使用客户端未过期的缓存）
- 307 Temporary Redirect 临时重定向 类似302，每种浏览器行为不一致
- 400 Bad Request 表示请求报文中存在语法错误
- 401 Unauthorized 表示发送的请求需要通过HTTP认证（BASIC、DIGEST认证），若之前已经进行过一次请求，则表示用户认证失败
- 403 Forbidden 表示请求资源的访问被服务器拒绝了
- 404 Not Found 表示服务器上无法找到请求的资源
- 500 Internal Server Error 表示服务器执行请求时发生了错误
- 503 Service Unavailable 表示服务器处于超负载或者维护中，无法处理请求
HTTP的缺点
- 通信使用明文（不加密），内容可能会被窃听
- 不验证通信方的身份，有可能遭遇伪装
- 无法证明报文的完整性，有可能已遭篡改