美文网首页
Java知识框架 - Linux

Java知识框架 - Linux

作者: 码畜的快乐源泉 | 来源:发表于2020-03-09 17:57 被阅读0次
    • 内存淘汰算法
      • FIFO - 先进入缓存的会先被淘汰
      • LRU - 最近最少使用 - LinkedHashMap - removeEldestEntry
      • LFU - 存储成本&尾部易淘汰
      • W-Tiny-LFU - Caffine - 布隆过滤器
    • 网络IO模型
      • 阻塞IO - 单次recvfrom - 尝试一次,阻塞直到数据准备好,拷贝数据
      • 非阻塞IO - 多次recvfrom - 尝试多次,直到数据准备好,拷贝数据
      • 多路复用IO - select阻塞 - 进程等待多个socket,直到socket变为可读,拷贝数据
      • 信号驱动IO - 发送信号,立即返回,数据准备好,信号通知,拷贝数据
      • 异步IO - aio_read调用后立即返回,数据准备好,后台完成复制
    • select、poll、epoll
      • select/epoll核心是可以同时处理多个connection,而不是更快,所以连接数不高的话,性能不一定比多线程+阻塞IO好
      • 异步I/O(POSIX的aio_系列函数) - Future-Listener机制
      • select - 阻塞、轮询、单个进程打开的FD有限制,默认1024
      • poll - 和select一样,但是没有最大文件描述符限制
      • epoll - 回调机制、没有FD限制、内核和用户空间mmap同一块内存实现
    • epoll原理
      • 三个epoll相关的系统调用
        • int epoll_create(int size) - 建立一个epoll对象。size是保证能够正确处理的最大句柄数
        • int epoll_ctl(int epfd, int op, int fd, struct epoll_event event) - 操作epoll对象,将socket句柄加入到epoll中让其监控,或者把epoll正在监控的某个socket句柄移出epoll
        • int epoll_wait(int epfd, struct epoll_event event, int maxevents, int timeout) - 在给定timeout的时间内,所监控的句柄中有时间发生时,就返回用户态的进程
      • 内部实现 - 文件系统(file节点) -> 红黑树(socket句柄) -> list链表(准备就绪的event)
        • epoll初始化时,会向内核注册一个文件系统,用于存储被监控的句柄文件
        • 调用epoll_create时,会在这个文件系统中创建一个file节点
        • epoll会开辟自己的内核高速缓存区,以红黑树的结构保存句柄,以支持快速的查找、插入、删除
        • 还会再建立一个list链表,用于存储准备就绪的事件
        • 执行epoll_ctl时,把socket句柄放到epoll文件系统里file对象对应的红黑树上
        • 给内核中断处理程序注册一个回调函数,告诉内核,如果这个句柄的中断到了,就把它放到准备就绪list链表里
        • 当一个socket上有数据到了,内核在把网卡上的数据copy到内核中后,就把socket插入到就绪链表里
        • 当epoll_wait调用时,仅仅观察就绪链表里有没有数据,有数据就返回,没有就sleep,超时立即返回
    • 常用命令
      • netstat - netstat -ap | grep ssh
      • awk - awk '{pattern + action}' {filenames}
        • 列出早上10点访问量最多的20个url地址? - grep "07/May/2018:10:" /usr/local/var/log/nginx/access.log|awk '{print $12}'|sort -rn|uniq -c|head -20
      • sed - 主要用来自动编辑一个或多个文件、简化对文件的反复操作、编写转换程序等
    • TCP粘包拆包
      • 拆包 - 完整的包被TCP拆分为多个包进行发送
      • 粘包 - 多个小的包封装成一个大的数据包发送,Client发送的若干数据包,Server接收时粘成一个包
      • 发送方会使用Nagle算法,接收方会产生拆包粘包的问题,应用层解决半包读写的方法
    • TCP三次握手&四次挥手
      • 三次握手


        image.png
        • 三次握手详解
          • A -> B:seq信号x
          • B -> A:seq信号y,ack信号x+1
          • A -> B:seq信号x+1,ack信号y+1
        • 为啥会有三次握手
          • A给B发送的两端报文,第一段报文因为网络抖动还未到B,第二段报文先到了,就会造成报文错乱。
          • A给B的连接请求其实是过期的,如果没有三次握手,过期的连接请求到达B,连接就建立,B一直在等A发数据,A一直不发,这样B的许多资源就白白浪费了。
      • 四次挥手


        image.png
        • A -> B:seq信号u
        • B -> A:seq信号v,ack信号u+1
        • B -> A:seq信号w,ack信号u+1
        • A -> B:seq信号u+1,ack信号w+1
    • 网络传输数据链路
      • 输入域名->浏览器内核调度->本地DNS解析->远程DNS解析->ip->路由多层跳转->目的服务器->服务器内核->代理服务器Nginx/网关/负载均衡设备->目的服务器->服务器内核->应用程序(SpringBoot)->Redis->Mysql
    • HTTP
      • 状态码
        • 200 请求已成功,请求所希望的响应头或数据体将随此响应返回。
        • 301 被请求的资源已永久移动到新位置。
        • 302 请求的资源现在临时从不同的 URI 响应请求。
        • 400 1、语义有误,当前请求无法被服务器理解。2、请求参数有误。
        • 401 当前请求需要用户验证。
        • 403 服务器已经理解请求,但是拒绝执行它。
        • 404 请求失败,请求所希望得到的资源未被在服务器上发现。
        • 500 服务器遇到了一个未曾预料的状况,无法完成对请求的处理,会在程序码出错时出现。
        • 501 服务器不支持当前请求所需要的某个功能。无法识别请求的方法。
        • 502 作为网关或者代理工作的服务器尝试执行请求时,从上游服务器接收到无效的响应。
        • 503 由于临时的服务器维护或者过载,服务器当前无法处理请求。
      • HTTP2.0
      • HTTP报文
        • 请求报文 - 请求行(Request Line)、请求头部(Header)、空行(Blank)、请求数据(Request Body)
        • 响应报文 - 状态行、消息报头、响应正文
      • 幂等性 - GET是幂等的,POST是非幂等的
    • 网络攻击
      • CSRF - 跨站请求伪造、判断来源、加 Token
      • XSS - 跨站脚本攻击、内容转义、过滤、CSP
      • SQL注入 - SQL有问题、预编译
    • ISO七层模型
      • 1、物理层 - 建立、维护、断开物理连接
      • 2、数据链路层 - 在链路上误差错一帧一帧传送信息
      • 3、网络层 - 分组传输和路由选择 - 协议有:ICMP IGMP IP(IPV4 IPV6) ARP RARP
      • 4、传输层 - 经端到端从网络透明的传输报文 - 协议有: TCP/UDP
      • 5、会话层 - 建立、管理、终止会话
      • 6、表示层 - 数据格式的转换 - 格式有,JPEG、ASCll、DECOIC、加密格式等
      • 7、应用层 - 网络服务与最终用户的一个接口 - 协议有:HTTP FTP TFTP SMTP SNMP DNS

    相关文章

      网友评论

          本文标题:Java知识框架 - Linux

          本文链接:https://www.haomeiwen.com/subject/zfzpdhtx.html