计算机网络储备

此小节为回顾(总结开发必知必会的网络知识), 详细的细节请看"计算机基础"的内容.

# C/S

C client客户端与 S server服务端基于网络进行通信.
B/S 包含于 C/S. B指的是browser浏览器, 以浏览器作为客户端.

server端必须满足的两个条件:
1> 保证一套体系(网络 - 硬件 - OS - server的应用软件)的稳定运行
开发人员关注与服务端的应用软件即可,网络、硬件、Linux是运维负责的.
2> 服务端必须绑定一个固定的地址.(IP + 端口)

# 互联网

互联网 = 物理连接介质 + 互联网协议

Ps: 物理连接介质(光纤、电缆、交换机、路由器..)是网络运维管的.. 我们关注的是协议!!

"互联网协议即计算机界的英语"(全世界的通用语言是英语)
所有的计算机都得学会互联网协议,才能按照协议规定的标准组织数据沿着网络进行通信.

OSI组织根据互联网协议功能的不同,将其分为了七层: 应表会传网数物

但作为开发人员,只需要掌握五层: 应 - 传 - 网 - 数 - 物

协议	五层	标识地址的方式
HTTP、FTP、Email	应
TCP、UDP	传	ip + mac + port
IP	网	ip + mac
ethernet、arp	数	mac
高低电信号	物

# Ethernet协议

以太网协议有三大规定:

1> 规定一组电信号构成一个数据帧
2> 每一数据帧由报头head "固定长度18个字节" + 数据data两部分组成

源"mac"地址  目标"mac"地址  数据类型      DATA
   6bit         6bit       6bit     46-1500bit

1
2

3> 规定接入的internet的设备都必须具备网卡,每块网卡上在出厂的时候都烧录了全世界唯一的mac地址.
mac地址 48位二进制是,由16位十六进制数表示,前6位厂商编号,后六位流水线号.

思考? 有了以太网协议和物理连接介质,就能实现全世界计算机之间的通信了吗？
嗯! 理论上ok的. 但要知道以太网协议采用一种古老的方式通信: 广播.
有这样一句谚语: 计算机通信基本靠吼
真实情况下是不行的! 从两方面考虑:
一方面,产生大量的广播包 (就是数据帧,里面会有源mac地址和目标mac) 会造成网络风暴;
二方面,交换机的 mac地址表 (mac地址与交换机端口的映射) 不可能无限大.
交换机具备mac地址学习功能!

"吼"只能在当前所处的局域网/子网/网段/广播域中吼! 以太网协议的mac地址是走不出广播域的!!
mac地址能标识一台主机在局域网中的哪个位置.

# IP协议

IP协议有二大规定:

1> 规定每台计算机都得配一个IP地址 (现目前是IPv4地址)
IPv4地址遵照点分十进制组成,有四段,每段都是8位二进制数,换成十进制数,每段的范围都是0-255.
2> 规定发送的数据报由报头和数据两部分组成. 报头包含 源IP地址 和 目标IP地址!

IP地址和子网掩码作按位与运算,可以得到子网地址/网络地址!
若通信双方的主机的网络地址相同, 则用以太网协议,基于mac地址通过数据链路层的二层交换机进行广播.
若不相同,则需要跨局域网通信,涉及到路由协议(会有一个路由表)等.. 了解即可,无需掌握.
Ps: 不在同一局域网,会将数据包交给网关,数据包中"封装的目标mac是mac(网关)"

IP + mac地址能标识全世界范围内独一无二的一台计算机. 有时候只说IP是因为ARP在背后找到了MAC.
IP找到主机在哪个局域网,MAC找到主机在局域网的哪个位置!!

我们判断双方能否能成功通信,会ping对方的IP地址. 但这并不意味着,只需要IP地址就行啦! 
找到对方处于哪个局域网后,ARP协议会发送 "ARP广播包" 帮我们拿到此局域网里该IP对应的mac地址!!!

拿到目标mac后,再开始封装以太网协议的报头,发送真正的数据!

基于网络层和数据链路层如何进行通信的？细节请看 计算机网络之网络层 的内容.(开发了解即可)
内心OS:当时弄明白的过程也挺痛苦的..Hhh 想着以后计算机考研(408)会考计算机网络,也就舒坦了些许.先了解嘛!

1
2
3
4
5
6
7

# TCP/UDP协议

客户端软件与服务端软件通信,C找到S在哪还不够,还得找到S上运行的多个软件中的那一个!!

TCP和UDP是基于端口工作的协议
服务端每启动一个基于互联网通信的程序,都会对应一个本主机唯一的端口号!
端口号范围: 0 - 65535 0 - 1024 给操作系统预留的, 1025 - 65535给软件的.

IP + mac + port 能标识全世界范围内独一无二的一个基于网络通信的应用软件!!
因为ARP协议的存在,通常会说是 IP + port.

C/S都需要IP和port, 但服务端的IP和port需要固定!(哪怕宕机后重启也不能变!),客户端不需要固定.

# HTTP协议

应用软件工作在应用层, 自己写的应用软件可以自个儿定制应用层的协议!
比如: 浏览器这个应用软件就执行了http协议和tcp协议..

要知道, 通信最根本的目的是拿到整个互联网里想要访问的那个资源!!
上网的过程本质就是资源下载和上传的过程!

url 统一资源定位符号
url = 应用协议部分 + 域名和端口 + 路径

https://www.zhihu.com/column/c_1189883314197168128

应用协议部分      https://  # -- 也有可能是htp://
域名和端口        www.zhihu.com:80  # -- 默认端口号是80,浏览器后自动填充.
路径             column/c_1189883314197168128

注意:80是服务端的端口号,基于网络通信的web服务(提供网页服务的)都是绑定80端口. 约定俗成的.
常见默认端口: DHCP端口号67 ; DNS端口号53

1
2
3
4
5
6
7
8

url地址是用来标识全世界范围内独一无二的一个资源的!!
将url地址拆分,可以发现,url是建立在ip+mac+port之上的!

[浏览器打开一篇博客的过程!!]
        浏览器和用户进行交互 "用户点击某个链接" , 产生了一个url地址. 浏览器不着急发送请求.
        会先做一些准备工作:
             1> 将url中的域名发给DNS服务器进行 DNS域名解析 , 得到IP地址.
             2> 拿着IP和端口,浏览器基于TCP协议发送接收数据包与目标主机上的应用软件完成三次握手!!
注意,三次握手的过程中传输的数据包不包含用户真正要传输的数据;
即此时没有真正的数据在传输 ,TCP 三次握手建立的 双向通路 是在为传输数据做准备!!!
        此双向通道是逻辑上的! 建立好后, 浏览器会先按照自己定义的HTTP协议封装数据 , 将数据给操作系统 .操作系统再依次封装 tcp头、ip头、以太网头,最后调用网卡通过物理连接介质进行传输.. 目标主机收到后,进行拆包. 再封装浏览器需要的数据传输给浏览器.

Q: 为啥要先建立双向通路"本质上就是全双工通信"?
A: HTTP是比TCP更高层次的应用层协议. 根据规则,只有低层协议建立之后才能,才能进行更层协议的连接.
因此, 首先要建立TCP连接, 一般TCP连接的端口号是80...
此双向通路还可以解决丢包问题、顺序问题、效率问题等.

Q: 应用层什么时候就认为把数据发完了?
A: 应用层将数据丢给OS的时候, 应用层就不管啦!OS再按照协议开始运作.
So,要注意,应用层send操作发数据的时候,不是直接发给对方啦,而是先把数据给了OS!!

# 三次握手

三次握手建立TCP连接. 准确点说是一次握手过程中交换了三个报文!!
一定要晓得在发送真正数据之前,双向通路是没有建好的!!!

TCP协议是好人协议, Client向Server发送连接请求, S同意啦! 最后C再向S发送一个确认.

# SYN=1   请求报文 
# ACK=1   确认报文
# seq=x   序列号
# ack=x+1 确认号,表明x序号以前的都收到啦,期望下一次收到的序号是x+1

第一个报文   `C to S`
    SYN=1   seq=x 
第二个报文   `S to C`
    ACK=1   ack=x+1
    - - - - - - - -
    SYN=1   seq=y
第三个报文   `C to S`
    ACK=1   seq=x+1   ack = y + 1

1
2
3
4
5
6
7
8
9
10
11
12
13

[半连接池 backlog]

服务器第一次收到客户端的 SYN 之后, 就会处于 SYN_RCVD 状态, 此时双方还没有完全建立连接.
服务器会把这种状态下 请求连接 放在一个队列里, 我们把这种队列称之为半连接队列.
半连接池限制的是同一时间的请求数,而非连接数. 半连接池的大小为5,已连接数可以为100.
syn洪水攻击就会造成服务器大量SYN_RCVD状态出现..

当然还有一个全连接队列, 就是已经完成三次握手, 建立好的连接 就会放在全连接队列中.
如果队列满了就有可能会出现丢包现象.

[三次的原因]?

1> 通信双方确认彼此的收发数据的能力正常.
2> 只交换两次报文的话,服务端不能保证客户端已经收到了初始序列号.. 若第二个报文丢失, 客户端不晓得服务端的初始序列号, TCP的可靠性就无从谈起.
3> 若只交换两次报文. B一旦收到A的连接请求,回包后就表明连接已经建立啦.
当A给B的连接请求因为网络原因延迟了,A又重新发了连接请求,在AB连接断开后,旧的那个连接请求到达了B,AB之间又建立了连接.. B会苦苦等待A发数据过来.
4> 不是四次是因为,第二次的报文是没有传输真正的数据的,ACK+SNK一起传啦.
Ps: 第一个第二个报文不能携带真的数据,第三个报文是可以携带真正的数据的,因为客户端已经知道服务端的收发能力正常. 若第一个报文可以携带数据,那么攻击者就可以发送大量的报文让服务器占用大量内存进行缓存..

[TCP协议如何保证可靠传输!!!!!!]?

详见: https://blog.csdn.net/summer_fish/article/details/125259025

1> 字节编号机制!!
2> 数据段的确认机制!!
3> TCP超时重传机制!!

# 四次挥手

四报文握手断开连接

为什么是四次？想象一下建立好的TCP连接是双向的公路!

通常是服务端先发起断开连接的请求,进入 FIN_WAIT_1的状态.
在大并发的情况下,服务端会主动断开连接.会快速经过FIN_WAIT_1、FIN_WAIT_2,瞬间走到TIME_WAIT状态.
So,服务端大量连接处于TIME_WAIT状态,则证明有大量的访问!!

其余的请看计算机网络之传输层的内容!!

面试常问:
1> 为何建立连接需要三次, 断开连接需要四次?
2> 为什么TCP协议是可靠协议,UDP是不可靠协议？
可靠与不可靠不关乎有无连接建立. TCP传输数据的可靠在于它发数据后必须等对方确认后才会把这份数据从自己的内存中/发送队列中删除掉.若未得到确认,会重传. -- TCP超时重传机制.
UDP把数据发出去后,就立刻清除掉,根本不考虑对方是否已经收到. --- 效率高,但不可靠.数据不安全.
3> tcp协议建立连接与断开连接的状态信息以及表示的意义.
正常情况下,只会补捉到LISTEN、ESTABLISHED、TIME_WAIT状态.. 其余状态会很快很快.

← 复习 TCP简单实现→