分层模型
应用层一般为程序员经常使用的，就是和具体的协议，具体的程序打交道的层级
?linux实验? 通过nc连接 手动将协议发出去，查看响应?，
[root@centos7 ~]# nc www.baidu.com 80
GET / HTTP/1.0
HTTP/1.0 200 OK
Accept-Ranges: bytes
Cache-Control: no-cache
Content-Length: 9508
Content-Type: text/html
Date: Wed, 04 May 2022 15:20:15 GMT
P3p: CP=" OTI DSP COR IVA OUR IND COM "
P3p: CP=" OTI DSP COR IVA OUR IND COM "
Pragma: no-cache
Server: BWS/1.1
Set-Cookie: BAIDUID=63EB0077D5162BBD716F83210F72D5F3:FG=1; expires=Thu, 31-Dec-37 23:55:55 GMT; max-age=2147483647; path=/; domain=.baidu.com
Set-Cookie: BIDUPSID=63EB0077D5162BBD716F83210F72D5F3; expires=Thu, 31-Dec-37 23:55:55 GMT; max-age=2147483647; path=/; domain=.baidu.com
Set-Cookie: PSTM=1651677615; expires=Thu, 31-Dec-37 23:55:55 GMT; max-age=2147483647; path=/; domain=.baidu.com
Set-Cookie: BAIDUID=63EB0077D5162BBDA2C898464F4D4E5D:FG=1; max-age=31536000; expires=Thu, 04-May-23 15:20:15 GMT; domain=.baidu.com; path=/; version=1; comment=bd
Traceid: 1651677615282151399410029134630169336004
Vary: Accept-Encoding
X-Frame-Options: sameorigin
X-Ua-Compatible: IE=Edge,chrome=1
<!DOCTYPE html><html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"><meta content="always" name="referrer"><meta name="description" content="全球领先的中文搜索引擎、致力于让网民更便捷地获取信息，找到所求。百度超过千亿的中文网页数据库，可以瞬间找到相关的搜索结果。"><link rel="shortcut icon" href="//www.baidu.com/favicon.ico" type="image/x-icon"><link rel="search" type="application/opensearchdescription+xml" href="//www.baidu.com/content-search.xml" titl
[root@centos7 ~]# netstat -natp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1168/sshd
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 1169/cupsd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1430/master
tcp 0 0 127.0.0.1:6010 0.0.0.0:* LISTEN 2613/sshd: root@pts
tcp 0 0 127.0.0.1:6011 0.0.0.0:* LISTEN 2727/sshd: root@pts
tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 2220/redis-server 1
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 691/rpcbind
tcp 0 48 192.168.0.133:22 192.168.0.1:6674 ESTABLISHED 2727/sshd: root@pts
tcp 0 0 192.168.0.133:22 192.168.0.1:6631 ESTABLISHED 2613/sshd: root@pts
tcp 0 0 192.168.0.133:22 192.168.0.1:6638 ESTABLISHED 2630/sshd: root@not
tcp 0 0 192.168.0.133:59382 39.156.66.14:80 ESTABLISHED 2726/nc 传输控制层：TCP? UDP? ，TCP面向连接的，可靠的，通过三次握手建立连接，进行数据传输，四次分手。
长连接 / 短连接目前主要由应用层程序来决定的，可控制是否断开，TCP能支持。服务端实现方式为：在服务器中input输入流以前1.0是拿到一次就不读了，1.1开始有循环，可以一直读取数据。
三次握手来建立连接，怎么实现？
传输控制层发了个数据包，携带字段syn发出去，服务端收到了，回一个syn+ack回去，表示确认收到了，第三次，客户端回一个ack。
?三次握手成功，内存里会开辟资源，此时连接进入ESTABLISHED状态，四元组匹配，请求端的ip +端口 和服务端的ip+端口。和四元组匹配，就会转交给相应的进程去处理。可相互通信。如果客户端没收到ack 可进行重试，会有一定的可靠性。三次握手或者程序处于监听状态，对于我们而言，就是一个socket,就是对资源的一个包装。?
程序的读写，其实面向的是socket资源，读的是client的Recv队列，写的时候放到client的Send队列里面。代表服务端即使没有发数据过来，应用依然会去读Recv队列；程序其实只在和单机内部的内核在进行交互，内核如何发送数据出去，是内核进行实现处理的。三次握手，相当于客户端的传输控制层同服务端的传输控制层交互（内核负责处理），而应用程序APP同内核之间是阻塞，还是非阻塞还是多路复用，也就是IO模型（可参考文章网络IO流）；socket也叫做套接字（四元组 源IP+port +目标IP+port），插座与插头的关系,套在一起了，能够表示绝对唯一的连接；port端口号是内核提供的有约束的，数量是65535个。
服务端启动后，例：mysql会启动监听进程，占用3306端口号，只要有请求进来，目标端口号是3306就会分配给此进程，去分配资源建立连接。理论上一个客户端主机可以跟此服务端主机此3306端口建立65535个连接（取决于四元组匹配的唯一性）。
四次分手
分的是连接，就是资源释放的过程；因为是可靠连接，所以发分手信息过去都应该有回应。
?最后释放资源对双方都没影响；如果没有这样的流程，则会不可靠，可能存在突然又不想分手的情况；
如果建立连接后，如果网断开了，任何一端是否可以感知连接已经断开这个情况？由于双方是内存开辟资源，是上下层解耦的，没物理层的。所以此时是无法感知网络已经断开的。所以内核为了解决这个问题，内核有一个心跳，keepalive，在不用的时候也会发包过去，内核检查这个连接的心跳有没有，单独检查这个连接（四元组）的健康，即使程序不使用这个连接，也可以告诉你这个连接已经断了。应用程序也可以做心跳，应用层做的心跳，其实检查的是应用空间程序的一些角色的健康（比如某服务器宕机了，但其实还有一台备用机，可以拉起服务，应用程序检测发现服务失败了，可以从注册中心另外一台机器尝试建立服务，继续检测）
