网络相关问题

内容提要：
1.ISO七层协议是什么？各自的作用？
2.OSI的实现具体是怎样的？ TCP/IP协议族
3.TCP协议的
　　- 四个特性？
　　- TCP报文结构以及重要参数的含义？
　　- 什么是TCP三次握手？
　　　　- IP数据包分片细节？
　　　　- TCP粘包和拆包
　　　　- 网络抓包工具Wireshark
　　　　- 三次握手的过程，为什么需要三次握手才能建立连接
　　　　- 握手的隐患 -SYN超时
　　　　- 保活机制
6.什么是TCP的四次挥手？
　　- 为什么会有TIME_WAIT状态？
　　- 为什么需要四次挥手才能中断连接？
　　- 服务器出现大量CLOSE_WAIT状态的原因？
7.什么是UDP协议
　　- 报文结构
　　- 特点
8. TCP和UDP的区别
9. RTT和RTO概念
10. TCP的滑动窗口作用
11.HTTP超文本传输协议
　　- 特点
　　- 报文结构
　　- HTTP请求响应步骤
　　- 在浏览器地址栏键入URL，按下回车后经历的流程？
　　- GET请求和POST请求的区别
　　- Cookie和Session的区别
12. HTTPS = HTTP + SSL或TLS
13. Socket编程

 
 
ISO七层协议是什么？各自的作用？
 
1.物理层：两台物理机之间的通信需求，具体要做的是机器A往机器B发送Bit流，机器B能收到该Bit流。  定义了物理设备的标准，如网线的类型，光纤的接口类型。 机器A的二进制Bit流数据转化为电流强弱进行传输，到达B后电流强弱转化为二进制Bit流，也叫做数模转换与模数转换。  网卡工作在这一层
 
2.数据链路层：传输的Bit流存在错传和不完整的可能，定义了如何格式化数据，如何传输，如何控制对物理介质的访问，还提供错误检测和纠正，以确保数据传输的可靠性。 这一层将Bit数据转化为帧，交换机工作在这一层，该层会对帧解码。
 
3.网络层：点对点通信需要通过多个节点， 如何找到目标节点，如何选择最佳路径是这一层要解决的问题。  主要作用是将网络地址翻译为对应的物理地址，并决定如何将数据从发送方路由到接收方。综合考虑发送优先权， 网络拥塞程度，服务质量以及可选路由的花费来决定A到B的最佳路径。 路由器属于网络层。这一层的数据我们称为数据包。关注IP协议；
 
4.传输层：发送海量数据的需要，网络可能不稳定或中断，为了保证传输大量数据时的准确性，需要对发送的数据进行切分，切分成Segment段落进行发送，Segment丢失，是否需要重传，是否顺序到达。  是最重要的一层，可以进行流量控制 ，还可以根据接收方接受数据的快慢程度 规定适当的发送速率。 需要关注TCP/UDP协议。
 
5.会话层： 用户级别的体验并不好，为了不需要每次调用IP协议找路由，调用TCP协议去打包。因此我们要建立一个自动收发包，自动寻址的功能。 这就是会话层的作用，建立和管理应用程序之间的通信。
 
6.表示层：解决不同系统之间的通信语法问题，比如Linux和Windows的通信中针对不同系统进行格式化数据。
 
7.应用层：转化成系统能理解的字节数组之后，需要制定字节拆分规则。所以应用层规定发送方和接受方必须使用一个固定解析规则或长度的消息头。重点关注HTTP协议。
 
 
OSI开放式互联参考模型
 
 
OSI的实现具体是怎样的？
 
TCP/IP协议簇
 
 
TCP/IP协议簇-数据处理
 
 
 
 
 
 
 
TCP协议的特性？
 
1.面向连接，可靠的，基于字节流的传输层通信协议
2.将应用层数据流分割成报文段发送给目标节点的TCP层，最大报文段受到MTU（数据链路的最大传输单元）限制
3.数据包都是有序，对方收到则发送ACK确认，未收到则重传
4.使用校验和来检验数据在传输过程中是否有误
 
 
TCP报文结构以及重要参数的含义？
 
 
SourcePort/DestinationPort ：端口，唯一表示进程(两个进程通信的方法：管道，内存共享，信号量，消息队列)，本地进程可以使用PID，不同的计算机则使用IP+协议+PORT来表示网络中的一个进程，在Java场合中也叫做套接字Socket；
 
Sequence Number：4字节，表示报文段的序号，如序号是107，携带内容为100字节，下一个报文段的序号为207开始
Acknowledgment Number：4字节，期望收到对方下一个报文段第一个数据字节的序号，如B收到A发送的报文，序号为301，携带数据为200字节，说明B收到了序号为500及之前的数据，则B期望收到A下一个报文段的序号为501.
 
Offset ：由于头部有可选字段，长度不固定，指出TCP报文的数据距离TCP报文的起始处有多远
Reserved：保留域，目前还是0
 
 
TCP Flags ： C E U A P R S F
URG ：紧急指针标志，1有效，0忽略
ACK：确认序号标志 1 有效 0 不含确认信息，忽略
PSH：push标志  1 表示收到报文应该尽快给到应用程序而不是在缓冲区排队
RST：重置连接标志  主机奔溃，错误连接或主机非法的报文段，拒绝连接请求
SYN：同步序号，用于连接建立过程 
FIN：finish标志，用于释放连接
 
window ：用来告知发送端或接收端的缓存大小，以此来控制发送端发送数据的速率，来达到流量控制
Checknum：对整个TCP报文 的校验和，发送端计算和存储，接收端验证。
Urgent Pointer ：TCP Flags=U时，指出紧急数据的字节数
TCP Option：可选参数
 
什么是TCP三次握手？
 
什么是全双工通信：A可以给B发送信息，B也可以给A发送信息
TCP的三次握手流程图：HTTP通信协议原理：http://www.solves.com.cn/it/wl/zs/2019-10-24/6599.html
netstat -n -p TCP | grep SYN_RECV
 
 
Wireshark抓包工具：
sudo spctl --master-disable
 
三次握手过程：
  1. 第一次握手，建立连接时，客户端发送SYN包(seq=x),到服务器，并进入SYN_SEND状态，等待服务器确认。
  2. 第二次握手：服务器收到SYN包，必须确认客户的SYN(ack=x+1)，同时自己也发送一个SYN包（seq=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；
  3. 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包（ACK=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
 
 
为什么需要三次握手才能建立起连接？
为了初始化Sequence Number的初始值。
作为以后的数据通信的序号，以保证以后的数据通信的数据不会因为网络上的问题而乱序。
TCP会用这个序号来拼接数据。
 
首次握手的隐患 — SYN超时
问题起因分析
  • Server收到Client的SYN，回复SYN-ACK的时候未收到ACK确认
  • Server不断重试直至超时，Linux默认等待63秒才断开连接，间隔为1，2，4，8，16，32秒
会导致SYN Flood攻击，客户端发SYN报文后下线，服务器不断重试耗尽SYN连接队列，不能处理正常连接。
防护措施：
  • SYN队列满后，通过tcp_syncookies参数回发SYN cookie（通过源地址端口，目标地址端口和时间戳打造出一个特别的Sequence Number回发）
  • 若为正常连接（直接把Syn Cookie发回来）则Clinet会回发SYN cookie，直接建立连接
 
建立连接后，Client出现故障怎么办？
保活机制 ：keepalivetime
  • 向对方发送保活探测报文，如果未收到响应则继续发送
  • 尝试次数达到保活探测数任未收到响应则中断连接
保活功能在默认情况下是关闭的TCP连接的任何一端都可以请求打开这一功能。保活功能可以被设置在连接的一端、两端,或者两端都没有。
在一段时间(称为保活时间,keepalivetime)内连接处于非活动状态,开启保活功能的一端将向对方发送一个保活探测报文。如果发送端没有收到响应报文,那么经过一个已经提前配置好的保活时间间隔(keepaliveinterval),将继续发送保活探测报文,直到发送探测报文的次数达到保活探测数(keepaliveprobe),这时对方主机将被确认为不可到达,连接也将被中断。
 
 
TCP的四次挥手
 
 
1.第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_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状态，完成四次握手。
 
为什么会有TIME_WAIT状态？2MSL（MSL为最大报文段生存时间，LWIP为1分钟，windows为2分钟）
原因：
  • 确保有足够的时间让对方收到ACK包（如果被动关闭的那方没有收到ACK就会触发被动端重发FIN包，一来一去正好是2MSL）
  • 避免新旧连接混淆（2MSL时间内之前连接的端口号不能使用，避免新的连接会接受到迟到的报文）
 
为什么需要四次挥手才能中断连接？
因为全双工，发送方和接受方都需要FIN报文和ACK报文；
 
服务器出现大量CLOSE_WAIT状态的原因？
对方关闭Socket连接，我方忙于读或者写，没有及时关闭连接。
  • 检查代码，特别是释放资源的代码
  • 检查配置，特别是处理请求的线程配置
 
这样会导致连接耗尽Linux句柄数，报too many open files错误；调整linux最大句柄数参考：https://www.cnblogs.com/likehua/p/3831331.html，默认为1024，最大为65536
 
CLOSE_WAIT演示：使用netstat和awk查看（awk借助管道逐行逐列的处理格式化的数据）
 
 
#netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’
LAST_ACK 14
SYN_RECV 348
ESTABLISHED 70
FIN_WAIT1 229
FIN_WAIT2 30
CLOSING 33
TIME_WAIT 18122
状态：描述
CLOSED：无连接是活动的或正在进行
LISTEN：服务器在等待进入呼叫
SYN_RECV：一个连接请求已经到达，等待确认
SYN_SENT：应用已经开始，打开一个连接
ESTABLISHED：正常数据传输状态
FIN_WAIT1：应用说它已经完成
FIN_WAIT2：另一边已同意释放
ITMED_WAIT：等待所有分组死掉
CLOSING：两边同时尝试关闭
TIME_WAIT表示处理完毕，等待超时结束的请求数。
LAST_ACK：等待所有分组死掉
 
 
UDP介绍
 
报文结构：
 
特点：
  • 面向非连接
  • 不维护连接状态，支持同时向多个客户端传输相同的消息
  • 数据包包头只有8个字节，额外开销较小
  • 吞吐量只受限于数据生成速率，传输速率以及机器性能
  • 尽最大努力交付，不保证可靠交付，不需要维持复杂的连接状态表
  • 面向报文，不对应用程序提交的报文信息进行拆分或者合并
 
 
TCP和UDP的区别
 
结论：
  • 面向连接 VS 无连接
  • 可靠性
  • 有序性
  • 速度
  • 量级
 
 
RTT和RTO
  • RTT（Round Trip Time）：发送一个数据包到收到对应的ACK，所花费的时间，由三部分组成：链路的传播时间（propagation delay),末端系统的处理时间，路由器缓存中的排队和处理时间（queuing delay）
  • RTO（Retransmission TimeOut）：重传时间间隔 
 
TCP的滑动窗口
Tcp连接断开和滑动窗口简介：https://www.cnblogs.com/edifydream/p/5535361.html
TCP使用滑动窗口做流量控制与乱序重排
  • 保证TCP的可靠性
  • 保证TCP的流控特性（window，用于接收方通知发送方还有多少缓冲区可以接收数据，发送方根据接收方的处理能力来发送数据，从而不会导致接受方处理不过来）
 
TCP协议头窗口，滑动窗口，流控制，拥塞控制关系：http://www.mamicode.com/info-detail-1642968.html
 
TCP会话发送方
窗口的滑动
 
TCP接收方：
 
 
HTTP 超文本传输协议
 
  • 基于请求与响应无状态的应用层的协议
  • HTTP1.1版本持续连接机制，keepalive
 
特点
  • 支持客户端/服务器模式
  • 简单快速
  • 灵活
  • 无连接
  • 无状态：对事务处理没有记忆能力
 
HTTP1.0/HTTP1.1/HTTP2.0
 
HTTP请求报文结构
实际报文：
 
 
HTTP响应报文结构
 
 
 
HTTP请求响应步骤：
  • 客户端连接到Web服务器
  • 发送HTTP请求
  • 服务器接受请求并返回HTTP响应
  • 释放TCP连接：连接为keepalive，连接会保持一段时间
  • 客户端浏览器解析HTML内容
 
在浏览器地址栏键入URL，按下回车后经历的流程：
  • DNS解析：浏览器缓存，系统缓存，路由器缓存，IPS服务器缓存，根域名服务器缓存，顶级域名服务器缓存。
  • TCP连接：ip和port
  • 发送HTTP请求
  • 服务器处理请求并返回HTTP报文
  • 浏览器解析渲染页面
  • 连接结束
 
五种取值：
  • 1XX：指示信息，表示请求已接收，继续处理
  • 2XX：成功
  • 3XX：重定向
  • 4XX：客户端错误：请求有语法错误或请求无法实现
  • 5XX：服务端错误
 
常见状态码：
  • 200 OK
  • 400 Bad Request：客户端请求语法错误，不能被服务器所理解
  • 401:请求无权限
  • 403 服务器接收到请求，但拒绝服务
  • 404：资源不存在
  • 500:服务器发生不可预期错误
  • 503:服务器不能处理客户堵啊请求，一段时间后可能恢复正常，如连接池打满
 
GET请求和POST请求的区别：
三个层面
  • HTTP报文层面：GET请求信息放在URL（长度限制 ），POST放在报文体
  • 数据库层面：GET符合幂等性和安全性，POST不符合
  • 其他层面：GET可以被缓存，被存储，POST不行
 
Cookie和Session
Cookie 客户端的解决方案
  • 是由服务器发送给客户端的特殊信息，以文本形式存放在客户端
  • 客户端再次请求的时候，会把Cookie回发
  • 服务器接收到客户端的请求后，会解析Cookie生成和客户端相对应的内容
 
Cookie的设置以及发送过程：
 
Session 服务器端的机制
  • 服务端的机制，在服务器保存信息
  • 解析客户端请求并保存session id，按需保存状态信息
实现方式：jsessionid
  • 使用Cookie来实现
  • 使用URL回写来实现
 
Cookie和Session的区别
  • Cookie存放在客户端浏览器上，Session数据放在服务器
  • Session相对于Cookie安全
  • Session占用服务器资源
 
 
 
 HTTPS简介（http://51meaning.cn/blog/?p=388）：HTTP下面加入了SSL或TLS层
 
 
 
 
  • SSL（Security Sockets Layer，安全套接层）
    • 为网络通信提供安全及数据完整性的一种安全协议
    • 是操作系统对外的API，SSL3.0后更名为TLS
    • 采用身份验证和数据加密保证网络通信的安去和数据的完整性
 
加密方式：
  • 对称加密：加密和解密都是用同一个密钥，如AES
  • 非对称加密：加密使用的密钥和解密使用的密钥是不相同的，如RSA
  • 哈希算法：将任意长度的信息转换为固定长度的值，算法不可逆，如MD5
  • 数字签名：证明某个消息或者文件是某人发出或认同的
 
HTTP数据传输流程：加密方式组合使用
  • 浏览器将支持的加密算法信息发送给服务器
  • 服务器选择一套浏览器支持的加密算法，以证书 （证书发布的CA机构，  有效期，公钥，证书所有者，签名等）的形式回发浏览器
  • 浏览器验证证书合法性，并结合证书公钥加密信息发送给服务器
  • 服务器使用私钥解密信息，验证哈希，加密相应消息回发浏览器
  • 浏览器解密响应消息，并对消息进行验证，之后进行加密交互数据
 
 
 
HTTP和HTTPS的区别
  • HTTPS需要到CA申请证书，HTTP不需要
  • HTTPS密文传输，HTTP明文传输
  • 连接方式不同，HTTPS默认443，HTTP默认80端口
  • HTTPS=HTTP+加密+认证+完整性保护，较HTTP安全
 
 
HTTPS真的安全吗？
 
  • 浏览器默认填充http://，请求需要进行跳转，有被劫持的风险
  • 可以使用HSTS（HTTP Strit Transport Security）优化
 
 
 
Socket是对TCP/IP协议的抽象，是操作系统对外开放的接口
 
Socket通信流程
 
 
 
 
 
posted @ 2019-11-09 12:52  天蓝隐湘  阅读(414)  评论(0)  编辑  收藏  举报