TCP/IP五层模型
OSI将计算机网络体系结构(architecture)划分为以下七层:
物理层: 在媒介上传输比特流;提供机械的和电气的规约
数据链路层:将分组数据封装为帧;在数据链路上实现数据的点到点、或点到多点方式的直接通信;差错检测
网络层: 定义逻辑地址;实现数据从源到目的地的转发
传输层: 建立、维护和取消一次端到端的数据传输过程。控制传输节奏的快慢,调整数据的排序等待
会话层: 在通信双方之间建立、管理和中止会话
表示层: 进行数据格式的转换,以确保一个系统生产的应用层数据能够被另外一个系统的应用层所识别和理解
应用层: 对应用程序提供接口
TCP/IP五层模型:应用层、传输层、网络层、数据链路层、物理层 ----物数网传应
- 应用层:为程序提供交互服务。在互联网中应用层协议有很多,如域名系统DNS、HTTP协议、SMTP协议
- 传输层:负责两台主机进程之间的通信提供数据传输服务。协议主要有传输控制协议TCP,用户数据协议UDP
- 网络层:选择合适的路由和交换节点,确保数据及时传送,包括IP协议
- 数据链路层:在两个相邻节点之间传送数据,将网络层交下来的IP数据包组装成帧,在两个相邻节点间的链路上传送帧
- 物理层:实现相邻节点间比特流的透明传输,尽可能屏蔽传输介质和物理设备差异
应用层常见的协议
- HTTP(超文本传输协议)
- SMTP(简单邮件传输协议)
- POP3/IMAP(负责邮件接收协议)
- FTP(文件传输协议)
- Telnet(远程登录协议)
- SSH(安全的网络传输协议)
TCP、UDP的区别
TCP:用于对传输准确性要求特别高的场景。如文件传输、发送和接收邮件、远程登录等
UDP:一般用于即时通信。如,语音、视频、直播等
下面是TCP和UDP的对比和区别:
TCP | UDP |
---|---|
面向连接 | 无连接 |
提供可靠服务 | 不保证可靠交互 |
有状态 | 无状态 |
面向字节流 | 面向报文 |
传输效率较慢 | 传输效率较快 |
有拥塞控制 | 没有拥塞控制 |
每一条TCP连接只能是 | 支持一对一、一对多、多对一、多对多 |
首部开销20字节 | 首部开销8字节 |
TCP的三次握手、四次挥手
三次握手
三次握手原理:
第1次握手:客户端发送一个带有SYN(synchronize)标志的数据包给服务端;
第2次握手:服务端接收成功后,回传一个带有SYN/ACK标志的数据包传递确认信息,表示我收到了;
第3次握手:客户端再回传一个带有ACK标志的数据包,表示我知道了,握手结束。
其中:SYN标志位数置1,表示建立TCP连接;ACK标志表示验证字段。
三次握手过程详细说明:
1、客户端发送建立TCP连接的请求报文,其中报文中包含seq序列号,是由发送端随机生成的,并且将报文中的SYN字段置为1,表示需要建立TCP连接。(SYN=1,seq=x,x为随机生成数值);
2、服务端回复客户端发送的TCP连接请求报文,其中包含seq序列号,是由回复端随机生成的,并且将SYN置为1,而且会产生ACK字段,ACK字段数值是在客户端发送过来的序列号seq的基础上加1进行回复,以便客户端收到信息时,知晓自己的TCP建立请求已得到验证。(SYN=1,ACK=x+1,seq=y,y为随机生成数值)这里的ack加1可以理解为是确认和谁建立连接;
3、客户端收到服务端发送的TCP建立验证请求后,会使自己的序列号加1表示,并且再次回复ACK验证请求,在服务端发过来的seq上加1进行回复。(SYN=1,ACK=y+1,seq=x+1)。
四次挥手
四次挥手原理:
第1次挥手:客户端发送一个FIN,用来关闭客户端到服务端的数据传送,客户端进入FIN_WAIT_1状态;
第2次挥手:服务端收到FIN后,发送一个ACK给客户端,确认序号为收到序号+1(与SYN相同,一个FIN占用一个序号),服务端进入CLOSE_WAIT状态;
第3次挥手:服务端发送一个FIN,用来关闭服务端到客户端的数据传送,服务端进入LAST_ACK状态;
第4次挥手:客户端收到FIN后,客户端t进入TIME_WAIT状态,接着发送一个ACK给Server,确认序号为收到序号+1,服务端进入CLOSED状态,完成四次挥手。
其中:FIN标志位数置1,表示断开TCP连接。
四次挥手过程详细说明:
1、客户端发送断开TCP连接请求的报文,其中报文中包含seq序列号,是由发送端随机生成的,并且还将报文中的FIN字段置为1,表示需要断开TCP连接。(FIN=1,seq=x,x由客户端随机生成);
2、服务端会回复客户端发送的TCP断开请求报文,其包含seq序列号,是由回复端随机生成的,而且会产生ACK字段,ACK字段数值是在客户端发过来的seq序列号基础上加1进行回复,以便客户端收到信息时,知晓自己的TCP断开请求已经得到验证。(FIN=1,ACK=x+1,seq=y,y由服务端随机生成);
3、服务端在回复完客户端的TCP断开请求后,不会马上进行TCP连接的断开,服务端会先确保断开前,所有传输到A的数据是否已经传输完毕,一旦确认传输数据完毕,就会将回复报文的FIN字段置1,并且产生随机seq序列号。(FIN=1,ACK=x+1,seq=z,z由服务端随机生成);
4、客户端收到服务端的TCP断开请求后,会回复服务端的断开请求,包含随机生成的seq字段和ACK字段,ACK字段会在服务端的TCP断开请求的seq基础上加1,从而完成服务端请求的验证回复。(FIN=1,ACK=z+1,seq=h,h为客户端随机生成)
至此TCP断开的4次挥手过程完毕。
HTTP协议的特点
- HTTP允许传输任意类型的数据,传输的类型由Content-Type加以标记
- 无状态。对于客户端每次发送的请求,服务器都认为是一个新的请求,上一次会话和下一次会话之间没有联系
- 支持客户端/服务器模式
浏览器中输入URL返回页面过程
- 解析域名,找到主机IP
- 浏览器利用IP直接与网站主机通信,三次握手后,建立TCP连接。浏览器会以一个随机端口向服务端的web程序80端口发起TCP连接
- 建立TCP连接后,浏览器向主机发起一个HTTP请求
- 服务器响应请求,返回响应数据
- 浏览器解析响应内容,进行渲染,呈现给用户
HTTP和HTTPS的区别
HTTP | HTTPS |
---|---|
超文本传输协议,信息明文传输 | 具有安全性的ssl加密传输协议 |
80端口 | 443端口 |
运行在TCP协议上 | 运行在SSL协议上,SSL运行在TCP上 |
需要CA机构申请证书,一般需要一定的费用 |
GET、POST的区别
GET | POST |
---|---|
参数通过URL传递 | 参数放在请求体中 |
只能进行url编码 | 支持多种编码方式 |
请求会被浏览器主动缓存 | 手动设置 |
请求参数会被完整保留在浏览器历史记录里 | 参数不会被保留 |
产生一个TCP数据包(把请求头和请求体一并发出去) | 产生两个TCP数据包(先发送请求头,服务器响应100continue,再发送请求体) |
什么是数字证书
服务器端可以向证书颁发机构(CA)申请证书,以避免中间人攻击(防止证书被篡改)
证书包含
- 证书内容
- 证书签名算法
- 签名
服务端把证书传输给浏览器,浏览器从证书里取公钥。证书可以证明该公钥对应本网站
数字签名的制作过程
1、CA使用证书签名算法对证书内容进行hash运算
2、对hash后的值用CA的私钥加密,得到数字签名
浏览器验证过程
1、获取证书,得到证书内容、证书签名算法、数字签名
2、用CA机构的公钥对数字签名解密(由于是浏览器信任的机构,所以浏览器会保存它的公钥)
3、用证书里的签名算法对证书内容进行hash运算
4、比较解密后的数字签名和对证书内容做hash运算后得到的哈希值,相等则表明证书可信
什么是cookie和session
由于HTTP协议是无状态的协议,需要用某种机制来识别具体的用户身份,用来追踪用户的整个会话。常用的会话跟踪协议是cookie、session
cookie就是由服务器发送给客户端的特殊信息,而这些信息以文本文件的方式存放在客户端,然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息。说得更具体一点,当用户使用浏览器访问一个支持cookie的网站的时候,用户会提供包括用户名在内的个人信息并且提交至服务器;接着,服务器在客户端回传相应的超文本的同时也会发回这些个人信息,这些信息存储于HTTP响应头中。当客户浏览器接收来自服务器的响应之后,浏览器将信息存放在一个统一的位置。自此,客户端再向服务器发送请求的时候,都会把相应的cookie存放在HTTP请求头,再次发回至服务器。服务器在接收到客户端浏览器的请求之后,就能够通过分析存放于请求头的cookie得到客户端持有的信息,从而动态生成与该客户端相对应的内容,网站的登录界面中“请记住我”这样的选项,就是通过cookie实现的
session原理:首先浏览器请求服务器访问web站点时,服务器首先会检查这个客户端请求是否已经包含了一个session标识,称为SESSIONED,如果已经包含了一个sessionid则说明以前为此客户端创建过session,服务器就按照sessionid把这个session检索出来使用,如果客户端请求不包含sessinon id,则服务器为此客户端创建一个session,并且生成一个与此session相关联的独一无二的sessionid存放到cookie中,这个sessionid将在本次响应中返回到客户端保存,这样在交互的过程中,浏览器每次请求时,都会带着这个sessionid,服务器根据这个sessionid就可以得到对应的session。以此来达到共享数据的目的,session不会随着浏览器的关闭而死亡,而是等待超时时间
sion,并且生成一个与此session相关联的独一无二的sessionid存放到cookie中,这个sessionid将在本次响应中返回到客户端保存,这样在交互的过程中,浏览器每次请求时,都会带着这个sessionid,服务器根据这个sessionid就可以得到对应的session。以此来达到共享数据的目的,session不会随着浏览器的关闭而死亡,而是等待超时时间