为什么80%的码农都做不了架构师?>>>
查看系统负载
1 w 命令
w命令用于显示系统当前负载 和系统已登录的用户.
-
查看系统CPU 和核数:
cat /proc/cpuinfo| grep 'cpu cores'
-
第一行显示 :
04:41:16 up 8:56, 1 user, load average: 0.00, 0.01, 0.05
- 第一列:
04:41:16
: 系统当前时间 - 第二列:
up 8:56
: 系统启动距离上次开启多长时间 - 第三列:
1 user
: 系统当前登陆用户数 load average: 0.00, 0.01, 0.05
系统负载, 1分钟, 5分钟, 15分钟 内平均
- 第一列:
2. uptime
显示w 命令显示的第一行, 仅显示系统负载相关信息.
3. vmstat
意思是静态显示内存状态。
[root@node10012 ~]# vmstat 1 -n
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 2750972 2108 907340 0 0 2 5 32 35 0 0 100 0 0
0 0 0 2750848 2108 907340 0 0 0 0 137 136 0 0 100 0 0
- 主要注意 swpd , bi, bo, wa 分别是内存是否吃紧, i/O 性能是否, 以及等待IO被阻塞的进程数.
3. top 命令
语法: top [options]
选项:
-b: 批量处理模式
-c: 显示详细信息
-bn1: 静态显示所有进程( 多用于shell脚本中)
监控网络性能
4. sar 命令
-
sar 常用于查看网卡流量
sar -n DEV [m[ n]]
-
需要关注
- rxpck/s 表示 接收的数据包数量
- txpck/s 表示 发送的数据包数量
- rxkB/s 表示接收的数据量
- txkB/s 表示发送的数据量
-
sar 查看磁盘读写信息
sar -b
-
显示
- tps 每秒传输到物理设备总次数, 传输对物理设备I/O请求, 多个逻辑请求可以组合
- rtps 每秒发送给物理设别的读请求的总数
- wtps 每秒发送给物理设备的 写请求总数
- bread/s 每秒为单位, 从设备读取数据总量, 块相当于扇区, 并且有512 字节的大小
- bwrtn/s s 为单位, 从设备 写数据总量, 块相当于扇区, 并且有 512 字节的大小.
5. nload
nload 可以看出设备的出入口流量的动态图, 分辨显示出入流量.
IO 性能监控
6. iostat
iostat
7. iotop
类似与top 命令, 用来动态监视磁盘 I/O 使用状况, 可以看出用户, PID, 进程相关信息, 以及读写速率.
8 free
free 命令可以看出系统的内存使用状况,
- CentOS 7 需要关注 available 列, 表示 剩余可用的, free列并不是剩余可用.
[root@node10012 ~]# free
total used free shared buff/cache available
Mem: 3863568 204884 2436848 13764 1221836 3315956
Swap: 2097148 0 2097148
9. 进程状态
- 进程状态:
- D: 不可中断
- R Running 状态的进程
- S Sleep 进程
- s 主进程
- T 暂停的进程
- Z 僵尸进程
- < 高优先级进程
- N 低优先级进程
- L 内存中被锁定了内存分页
- l 多线程进程
-
-
前台进程
-
10. 查看线程
- 命令:
ps -eLf
网络管理
11. netstat
- 用于查看本地服务监听的端口或者本地的 Unix socket.
- 选项:
-a: all 显示所有选项, 默认不显示 LISTEN 相关
-t: tpc 仅显示tcp 相关
-u: 显示 udp 相关
-n: 不显示别名, 转化成数字
-l: 查看listen 的端口
-p: 显示建立相关的链接程序名
-r: 显示路由信息
-e: 显示扩展信息
-s: 按协议统计
-c: 每隔一段时间执行 netstat
- 常用方法:
- 列出所有监听的 tcp 端口:
netstat -tl
- 列出监听的 udp 端口
netstat -ul'
- 查看所有端口
netstat -an
- 列出所有监听的 tcp 端口:
12. tcpdump
tcpdump是用于在网络中抓包, 可以根据用户指定的需求, 然后输出相关内容, 也可以输入到文件中. 用于后续分析
-
监视指定网口设备的数据包
tcpdump -i eth1
-
指定监听的指定ip/host的包
tcp -i eth0 HSOT 1921.68.2.2
-
指定访问本地指定端口 的来源IP
tcpdump -n -i ens33 tcp port 22 and src host 192.168.10.1
1. TCP
1.1 TCP 是什么:
-
TCP 是面向连接, ke可靠的额字节流的 传输层通信协议. 在网络结构中, TCP 层位于IP层之上, 应用层下面, 不同于应用成之间需要可靠的, 相管道的连接, 但是IP层不提供流机制, 而是提供不可靠的包交换.
-
应用层项 TCP 层发送用于网络传输, 用8位字节表示数据流,然后TCP把数据流封装成适当长度的报文, 之后TCP 把结果报传输给 IP层, 通过网络将包 发送给接收端 的TCP 层, 每个包都有一个序号, 当接收端接受到该包时, 会回复确认信息包(里面包含接受到的包的序号, 以及该包的序号), 同时序号也保证了自己的信息包的准确性,
1.2 tcp 功能
-
当应用层 向TCP 层发送用于网络传输的 8位字节表示的数据流, TCP 会将数据流分割成适当长度, 最大传输段 通常是由计算机连接的网络链路层最大传输单元(MTU)限制, 之后TCP 把数据包传给IP层, 通过网络将包传递给接受端.
-
tcp 为了保证报文传输的可靠, 就给每个表一个序号, 同时序号也保障了 传到接收端实体的包是按照顺序接收的, 然后接收端会对成功收的的包 回发一个确认(ACK),
-
如果发送端实体在 合理时间内(时延 RTT)没有收到对方的确认信息, 会认为数据丢失了, 将会重新发送对应的数据包.
-
数据正确性与合法性
- tpc 使用校验和和函数来校验 数据是否有错误, 同时可以使用 md5 对数据加密
- 在保证可靠性上, 采用超时重传和确认机制.
- 流量上, 采用滑动窗口协议, 协议中规定 未经过确认的分组需要重新传.
1.3 建立连接
- TCP 是 互联网中的传协议, 建立连接的方式是我们常说的'三次握手'.
- 主动方发出
SYN
请求, 等待对方回答SYN
+ACK
- 接收方 接收到
SYN
请求, 并对SYN
请求执行ACK
确认
-过程: + 客户端发送 SYN
(SEQ=x) 报文给服务端, 进入 SYN_SEND 状态 + 服务端接收到 SYN
报文后, 回应一个 SYN
(SEQ=y), ACK
(ACK=x+1) 既然怒 SYN_RECV 状态. + 客户端收到服务端的 SYN
报文, 回应一个ACK
(ACK= y+1) 报文, 进入 Establish 状态.
-
三次握手结束, TCP 客户端和服务端成功建立了连接, 可以传输数据了
-
TCP 标志位有6中表示
- SYN (synchronous 建立连接)
- ACK (Acknowlendgement 确认)
- PSH (push 传输)
- FIN (finish 结束)
- RST (reset 重置)
- UGR (urgent 紧急)
- Sequence number (顺序 号码)
- Acknowlendge number (确认号码)
-
第一次握手:
- 客户端 发送
SYN=1
(请求建立连接), 并产生随机确认码SEQ=NUM1
- 服务端 收到
SYn=1
的TCP 连接请求.
- 客户端 发送
-
第二次握手:
- 服务端 发送
ACK=NUM1+1
, 这里NUM1+1
就是 请求建立连接的随机码+1, 并产生自己的随机码SEQ=NUM2
- 服务端 发送
-
第三次握手:
- 客户端 收到后确认对方发送的
ACK=NUM
是否正确, 如果正确, - 将会回复服务端确认信息, 将接收到的
SEQ=NUM2
+1 并写入 恢复信息的ACK=NUM
中
- 客户端 收到后确认对方发送的
1.4 断开连接
-
TCP 在建立连接后是全双工工作的, 因此每个方向都是可以单独进行关闭的, 原则上是主动关闭一方 发送 FIN 报文表示终止这个方向连接, 收到一个FIN 意味着这个方向不再有数据流动, 但还另一个方向还可以发送数据, 知道另一个方向 发送 FIN 报文.
-
释放过程:
-
- 客户端进程向服务端发出释放连接请求报文, 并停止发送数据, 主动关闭TCP 连接.
- 释放报文段中, 控制符为 FIN=1, 序列号 seq=i 发送报文后客户端进入FIN_WAIT_1(终止阶段1)状态, 等待服务端确认, 这是第一次挥手.
-
- 服务端接收到释放请求报文后 发出确认释放请求的报文段,
- 释放报文段, 控制位为 ACK 确认号为 ack=i+1,
- 此时TCP 报文处于瓣关闭阶段, 客户端不在向服务端发送数据, 但是服务端任可以发送数据, 这是第二次挥手
-
- 客户端收到服务器确认信息, 进入 FIN_WAIT_2(终止状态2),
- 客户端等待服务器发出连接释放请求报文, 如果没有数据传输, 服务器被动项客户单发出释放连接请求报文
- 报文控制位为 FIN, 序列号为 seq=j 服务器进入 LAST_ACK (最后确认) 状态, 等待客户单确认应答, 这是TCP 连接释放的第三次挥手
-
- 客户端收到服务端释放请求后, 必须对此请求确认.
- 确认报文控制位 ACK , 确认应答号为 ack=j+1 , 客户单发出消息后进入 TIME_WAIT (时间等待)状态, 这段时间内 TCP 连接没有释放, 必须等待 2MSL 时间后, 客户单才进入 CLOSED 状态.
- 服务段收到确认应答后, 进入 CLOSED 状态了, 双方都进入 CLOSED 状态, 表示连接释放了, TCP 第四挥手完成.
END