OSI七层模型
应用-运输（表示+会话+传输)-网络-链路-物理
| 层级 | 作用 | 样例 |
|---|---|---|
| 应用层 | 为网络应用提供访问OSI环境手段 | FTP |
| 表示层 | 处理两个通信系统中交换信息的表示方式 | |
| 会话层 | 两个节点之间建立端连接。具体管理两个用户和进程之间的对话 | |
| 传输层 | 常规数据递送-面向无连接或有连接 | TCP/UDP。这里叫segment |
| 网络层 | 通过寻址来建立两个节点之间的连接 | IP。这里叫packet |
| 数据链路层 | 将数据分帧，并处理流控制 | 网卡、交换机。这里叫frame |
| 物理层 | 利用物理传输介质来为第二层提供物理连接 | 网线。比特流 |
在传输层tcp+data，传给网络层，封装为ip+data，传给链路层，以太hdr+data+以太ftr，封装结束。
封装结束后通过总线到达主机接口，再通过网线被送到主机A的接口，然后把报头层层去掉，给应用层
- ARP：完成了MAC与IP地址的映射。发送到dst时，若ARP里面有IP对应的MAC，就直接发；
没有就ARP请求获得MAC
TCP（Transmission Control Protocol）
- 如何保证正确性？
- 数据别校验：checksum。若出错就丢弃报文，然后发送端超时重发
- 对乱序数据包重排序：顺序后才交给应用层
- 丢弃重复数据
- 应答机制：ack。发送一个确认
- 超时重发
- 流量控制：每一方都有固定大小的缓存空间，接收端只允许另一端发送接收端缓冲区所能接纳的数据，可以防止较快主机致使较慢的缓冲区溢出。通过sliding window
- 三次握手
- 我要和你连接；你真的要和我连接吗？；我真的要！
- 原因：
为了防止已失效的链接请求报文突然又传送到了服务端产生错误。简单来说就是某一次client的请求延迟到了，事实上client已经不想连接了，但是server以为要连，然后建立连接，这时client忽略了server的请求，但是server一直在等client发送data，就浪费了资源
- 四次挥手
- 我要和你断开；好的断吧；我也要和你断开好的，断吧
- 最后一个ACK的作用：
在主动发起close的一方，发送最后一个ACK后会进入time_wait状态（应该说在保持2MSL（Maximum Segment Lifetime）恢复。
有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。
- 如何避免占用资源
改变服务器SO_REUSEADDR套接字选项来通知内核来让time_wait状态下端口仍然能重用 - tcp头有多少字节？哪些字段？
4位头部长度：标识tcp头部有多少字节
6位保留（flag）：ACK确认号是否有效、RST是否要对方重新连接、SYN表示请求一个连接、FIN通知关闭。
16位窗口大小：告诉tcp缓冲区还能容纳多少字节
16位校验和：有发送端填充，接收端对报文执行CRC判断tcp是否损坏
tcp选项：窗口扩大因子(TCP Window Scale Option)来增加TCP接收窗口的大小而超过65536字节 - connect操作会阻塞，怎么办？
设置connect非阻塞，立即返回值。然后把sockfd加入select读写监听集合，通过select判断sockfd是否可写。即让select来等待连接完成，同时给select设置一个时间限制 - 长连接和短连接的区别
- 长连接：在一个TCP上可以连续发送多个数据包；若无数据包（心跳），则需要发送检测包以维持连接多用于频繁的读写，而且连接数不能太多的情况
- 短连接：通信双方有数据交互时，就建立一个TCP连接，数据发送完成后立即断开此连接。web网站的一般都是短连接，因为用户基数大，如果每个用户都长连接的话消耗资源
UDP（User Datagram Protocol）
- udp调用connect有什么用
与tcp的connect不一样，tcp会触发三次握手，而udp仅仅是把ip&port给记录下来。
tcp只调用一次，udp可以调用多次，作用：1.记录新的ip&port2.断开之前的
TCP与UDP对比
| 类型 | TCP | UDP |
|---|---|---|
| 是否连接 | 是 | 否 |
| 传输可靠性 | 可靠 | 不可靠 |
| 应用场合 | 传输大量数据 | 少量数据 |
| 速度 | 慢 | 快 |
| 正确性 | 保证 | 丢包 |
| 复杂性 | 复杂 | 简单 |
| 应用场景 | qq文件 | qq语音视频 |
| 安全性 | 容易被攻击 | 不容易被攻击 |
拥塞控制机制
- 网络拥塞：对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏，这种情况就叫做网络拥塞
四种解决方案：
发送方：维护拥塞窗口cwnd的状态变量。取决于拥塞程度。将拥塞窗口作为发送窗口，即swnd=cwnd。维护一个慢开始门限ssthresh状态变量。cwnd < ssthresh慢开始，否则拥塞避免。慢开始（指数增长）
发送方当前只能发送一个数据报文段（拥塞窗口cwnd的值是几，就能发送几个数据报文段），接收方收到该数据报文段后，给发送方回复一个确认报文段，发送方收到该确认报文后，将拥塞窗口的值变为2；后续就是2、4、8.。。之后改用拥塞避免算法拥塞避免
每个传输轮次，拥塞窗口cwnd只能线性加一，而不是像慢开始算法时，每个传输轮次，拥塞窗口cwnd按指数增长。
假设24个报文段在传输过程中丢失4个，接收方只收到20个报文段，给发送方依次回复20个确认报文段，一段时间后，丢失的4个报文段的重传计时器超时了，发送发判断可能出现拥塞，更改cwnd和ssthresh.并重新开始慢开始算法。（发生超时重传）
快重传
发送方发送1号数据报文段，接收方收到1号报文段后给发送方发回对1号报文段的确认，在1号报文段到达发送方之前，发送方还可以将发送窗口内的2号数据报文段发送出去。
就是使发送方尽快进行重传，而不是等超时重传计时器超时再重传。
接收方在收到了失序的报文段也要立即发出对已收到的报文段的重复确认
发送方一旦接受到了三个连续的重复确认，就将相应的报文立即重传，而不是等该报文段的超时重传计时器。此时开始执行快恢复算法快恢复
ssthresh和cwnd调为原来的一半，再执行拥塞避免算法
第一二个方法的缺点：个别报文段意外丢失，但是没有阻塞，误认为发生拥塞，cwnd再次设为1，降低传输效率
Http与Https
http协议运行在tcp之上，明文传输，客户端/服务器无法验证对方身份。https是身披ssl的，添加了加密和认证机制的http。https开销大。
- http请求方式：
- option：返回服务器对特定资源所支持的HTTP请求方法
- head：向服务器索要与GET请求相一致的响应，只不过这响应不会返回
- get：向特定资源发送请求
- post：向特定资源提交数据进行处理请求，数据被包含在请求体中。可能会导致新的资源的创建或已有资源的修改
- put：向指定资源上传其最新内容
- delete：请求服务器删除request-URL所标识的资源
- trace：回显服务器收到的请求，主要用于测试或判断
- connect：HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器
- get和post区别：
get是获取资源，post是更新资源。get的请求url后面会有?带的参数，post会把数据放置在http请求的请求体中
网络安全
- DDos攻击：是什么？
没有根治的方法，除非不使用tcp
Session与Cookie
| 类型 | session | cookie |
|---|---|---|
| 实现机制 | 依赖于cookie | |
| 大小限制 | 无 | 有 |
| 安全性 | 在服务器端，安全 | 本地有可能被攻击 |
| 服务器资源消耗 | 在服务器上保留一段时间消失 | 过多会增加服务器压力 |
select和epoll
| select | epoll | |
|---|---|---|
| 时间 | 毫秒 | 微秒 |
| unix | 支持 | 有些不支持 |
| fd限制 | 有最大fd设置 | 没有 |
- 为什么select比epoll慢？
- select可以监听文件描述符是有限的，epoll可监听的文件描述符的个数为进程可打开的文件的个数。
- select中，当有事件就绪时，内核修改参数以通知用户，用户需要遍历所有的fd判断是哪个fd就绪，应用程序索引就绪文件描述符的时间复杂度是O(n)，IO效率随着监听的fd的数目增加而线性下降。
而epoll中注册了回调函数，当有就绪事件发生的时候，设备驱动程序调用回调函数，将就绪的fd添加到rdllist中，调用epoll_wait时，将rdllist上就绪的fd发送给用户，应用程序索引就绪文件描述符的时间复杂度是O(1)，IO效率与fd的数目无关。
epoll支持ET模式，当内核将该事件通知给用户后，用户必须立即处理，这样就减少了可读、可写、异常事件被触发的次数。
select只能工作在相对较低效的LT模式
- epoll有哪些触发模式？
水平与边缘