【网络】计算机网络自顶向下读书笔记
一、应用层
1.应用体系结构：C/S体系结构、P2P体系结构
1）C/S客户-服务器体系结构：总有一个打开的服务器，来服务来自不同用户的请求。（web、FTP\电子邮件）
2）P2P应用程序在间断连接的主机使用直接通信。（下载器迅雷、文件共享、视频会议）
2.网络通信的本质是：不同主机上的不同进程使用socket套接字进行通信。同一端上的进程可以通过管道 共享内存 消息队列通信。
3.对应用服务进行分类：可靠数据传输、吞吐量、定时、安全性。
4.应用层协议及对应底层协议：
TCP：SMTP\POP3\HTTP\FTP
UDP: DNS
5.HTTP大全：
6.get与post的区别：
get不安全 参数都在URL上，post 参数在实体里面。导致get传参有限、参数留在历史记录中、之能接受ASCII字符。
get head和data一起发送。post先发送header 再发送data，两次连接。
7.cookie和session的区别：
cookie存在客户端 session存在服务端。
cookie存在于我们的HTTP报文里，不安全 可能被盗取本地cookie并进行cookie欺骗。
session太多会引起服务器资源占用过多。
session需要使用cookie里面的session id来进行识别与确认。
8.电子邮件 异步通信媒介。三大组成：用户代理（outlook）、邮件服务器、简单邮件传输协议。
9.SMTP负责 将邮件从发送方邮件服务器 发送到 接收方邮件服务器。
10.电子邮件流程：
a调用用户代理程序，并提供b的邮件地址，指示用户代理发送。
a的用户代理发送到a的邮件服务器，放在报文队列中。
a的邮件服务器发现新的报文，创建到b的邮件服务器的TCP连接 使用SMTP协议发送。（b服务器没开机则等待重试）
b使用邮件访问协议如POP3来进行邮件读取。
11.其他邮件访问协议：
1）POP3第三版的邮局协议
2）IMAP因特网邮件访问协议
3）HTTP
12.DNS因特网目录服务 运行在UDP上。
13.DNS的作用：转换主机名IP地址、主机别名（z.cn亚马逊中国）、邮件服务器别名（@qq.com的本质很长、繁琐）
14.DNS通过UDP的端口53发送。
15.DNS查询过程
dns的层次结构：根服务器、顶级域（com org edu）、权威服务器。
16.P2P文件分发
具体代表协议：BitTorrent
参与一个特定文件分发的所有对等方集合叫 洪流。
a加入洪流 会将其余对等方的IP地址发给a，a根据列表创建TCP连接，连接上的叫邻近对等方，a询问邻近对等方持有的文件块，
发送a没有的块的请求，根据最稀缺技术，首先请求的是所有邻近对等方块副本最少的，其他邻近对等方也与a进行交换。
称为“一报换一报”。
17.CDN内容分发网络
CDN管理在多个地区的服务器上 在服务器上存储视频。
面向最终用户的内容提供设备，可缓存静态Web内容和流媒体内容，实现内容的边缘传播和存储，以便用户的就近访问。
操作过程：在DNS解析过程中，权威服务器发送CDN域的主机名，pc开启第二个DNS请求，返回CDN的ip地址，然后开启进行连接。
二、运输层
18.网络层提供了主机之间的逻辑通信，运输层提供了不同主机的进程之间的通信。运输层只工作在端系统上。
19.UDP用户数据报协议 不可靠、无连接的服务：数据交付、差错检查
TCP传输控制协议 可靠的、面向连接的协议：可靠数据传输、拥塞控制
可靠数据传输：流量控制、序号、确认、定时器
拥塞控制：慢启动，拥塞避免，快重传，快速恢复
20.网络层的IP协议是不可靠服务，尽力而交付服务。
21.数据交付包括：复用、分解
多路复用：将数据分组之后 装上运输层首部 传给网络层。
多路分解：将报文段根据套接字交付给正确的进程。
22.UDP套接字 二元组（目的IP地址，目的端口号）
TCP套接字 四元组（源IP 源端口号 目的IP 目的端口号）
23.UDP的优点
1）无需连接建立。不需要类似TCP的三次握手时延
2）无连接状态，服务器可以支持更多的用户连接
3）分组首部开效小 tcp首部20字节 udp首部8字节
4）udp将数据包不分组立即打包给网络层。
24.QUIC协议是HTTP/3的网络层协议 基于UDP 但是实现了可靠性。
TCP利用序号来保证可靠性 丢失的报文序号和后面都需要重传为了保证顺序性。
QUIC协议的重传是使用packet number，但是这个是永远递增的，当丢失了 会重选但是packet number还是+1
原因是使用同一个stream使用一个offset偏移量来表示 包的位置 通过不同的偏移量 交给接受方进行组合。
25.UDP报文段结构
26.分组接受到再接受其他分组，否则就一直等待。——停等协议。
允许发送方发送多个分组而无需等待确认。——流水线技术
27.解决流水线的差错恢复的两种办法： 都是基于滑动窗口的
1）GBN回退N步
所有分组按顺序分为 已确认 发送，还没确认 可用，还没发送 不可用
维护一个大小为n的窗口
发送方发送：
1上层调用rdt_send() 当窗口内有可用但没发送的分组进行发送，全为发送但未确认则返回
2收到一个分组n的ACK GBN采用累积确认 证明接受方正确收到n及以前的分组
3超时时间 对于某个n分组的ACK超时 发送方重传所有已发送但没确认的分组。
接受方：
接受到分组 则返回一个ACK
丢弃所有失序的分组，数据必须按序交付
2）SR选择重选
发送方：
每个分组都有自己的计时器 ，窗口内的分组超时后选择重传
接受方：
失序的分组先缓存起来
缺点：接受方的窗口和发送方的窗口不一样，会因序号导致错乱。解决：窗口长度必须小于等于序号空间大小的一半。
28.TCP协议只在端系统中运行，中间的路由器看不到TCP连接，只能看见数据报。
首部字段的细节：
1）32bit序号和32bit确认号 保证了tcp可靠性
2）16bit接受窗口 用于流量控制 表示接收方愿意接受的字节数量
3）选项：用于发送方和接受方协商MSS
4）标志字段：ACK确认字段的值有效、SYN、FIN等
5）4bit首部长度
29.三次握手的细节
- 第一次握手：Client将SYN置1，随机产生一个初始序列号seq发送给Server，进入SYN_SENT状态；
- 第二次握手：Server收到Client的SYN=1之后，知道客户端请求建立连接，将自己的SYN置1，ACK置1，产生一个acknowledge number=sequence number+1，并随机产生一个自己的初始序列号，发送给客户端；进入SYN_RCVD状态；
- 第三次握手：客户端检查acknowledge number是否为序列号+1，ACK是否为1，检查正确之后将自己的ACK置为1，产生一个acknowledge number=服务器发的序列号+1，发送给服务器；进入ESTABLISHED状态；服务器检查ACK为1和acknowledge number为序列号+1之后，也进入ESTABLISHED状态；完成三次握手，连接建立。
- 简单来说就是 ：
- 客户端向服务端发送SYN
- 服务端返回SYN,ACK
- 客户端发送ACK
SYN洪泛攻击：多个SYN请求，不完全第三步握手，导致服务器半连接，占用资源。
解决：使用SYN cookies，服务器不开连接不分配资源，而是传一个初始TCP序列号经过散列的cookie的SYNACK报文，如果接受到ACK则经过相同散列函数计算得到对映的ip地址、端口号，开启全连接。
两次握手行不行？双方都要发送一个自己的序列号，需要双双确认，这样就必须3次握手，2次最多确认一个序号。
30.四次挥手
- 第一次挥手：Client将FIN置为1，发送一个序列号seq给Server；进入FIN_WAIT_1状态；
- 第二次挥手：Server收到FIN之后，发送一个ACK=1，acknowledge number=收到的序列号+1；进入CLOSE_WAIT状态。此时客户端已经没有要发送的数据了，但仍可以接受服务器发来的数据。
- 第三次挥手：Server将FIN置1，发送一个序列号给Client；进入LAST_ACK状态；
- 第四次挥手：Client收到服务器的FIN后，进入TIME_WAIT状态；接着将ACK置1，发送一个acknowledge number=序列号+1给服务器；服务器收到后，确认acknowledge number后，变为CLOSED状态，不再向客户端发送数据。客户端等待2*MSL（报文段最长寿命）时间后，也进入CLOSED状态。完成四次挥手。
简单来说：
- 客户与服务器交谈结束之后，客户要结束此次会话，就会对服务器说：我要关闭连接了（第一 次挥手）
- 服务器收到客户的消息后说：好的，你要关闭连接了。（第二次挥手）
- 然后服务器确定了没有话要和客户说了，服务器就会对客户说，我要关闭连接了。(第三次挥 手)
- 客户收到服务器要结束连接的消息后说：已收到你要关闭连接的消息。(第四次挥手)，才关闭
为什么要四次挥手？close_wait的意义是什么？
- 因为服务器收到客户端断开连接的请求时，可能还有一些数据没有给客户端发完，这时先回复ACK，表示接收到了断开连接的请求。等到数据发完之后再发FIN，断开服务器到客户端的数据传送。（服务器端：客户端你让我断我就断啊，我这还没完事呢，等会再说）
TIME_WAIT的状态意义是什么？
30.TCP的报文长度：长度受限于MSS最大报文段长度，MSS受限于MTU最大链路层帧长度。
31.TCP协议只在端系统中运行，中间的路由器看不到TCP连接，只能看见数据报。
32.在Java中的socket是外观模式，为我们隐藏了很多TCP/IP协议的细节。
33.scoket通信过程：
-
基于TCP：服务器端先初始化Socket，然后与端口绑定(bind)，对端口进行监听(listen)，调用accept阻塞，等待客户端连接。在这时如果有个客户端初始化一个Socket，然后连接服务器(connect)，如果连接成功，这时客户端与服务器端的连接就建立了。客户端发送数据请求，服务器端接收请求并处理请求，然后把回应数据发送给客户端，客户端读取数据，最后关闭连接，一次交互结束。
-
基于UDP：UDP 协议是用户数据报协议的简称，也用于网络数据的传输。虽然 UDP 协议是一种不太可靠的协议，但有时在需要较快地接收数据并且可以忍受较小错误的情况下，UDP 就会表现出更大的优势。我客户端只需要发送，服务端能不能接收的到我不管
34.TCP使用端到端的拥塞控制，而不是网络辅助的拥塞控制，因为IP层不提供任何显示的拥塞反馈。
