├── CSE复习笔记.md ├── Cse note.md └── images ├── 4-7check.png ├── DMA-step1.png ├── DMA-step2.png ├── DMA-step3.png ├── DNS-Amplification.jpg ├── FS-creation.png ├── FS-open&write.png ├── FS-shadow.png ├── GFS-read.png ├── GFS-write-in-secondary.png ├── GFS-write.png ├── GFS.png ├── IDE-protocol--2.png ├── IDE-protocol.png ├── IO-structure.png ├── IP-spec-HEADER.png ├── MTTF-system.png ├── NFS.png ├── RAID4.png ├── RAID5.png ├── TCP-Retrofitting.png ├── abstractions.png ├── abusolute-find-by-name.png ├── arp-hacker.png ├── arp-middle-attack.png ├── async-network.png ├── compareandswap.png ├── create-timeline.png ├── customers&peers.png ├── cylinder-group.png ├── demultiplexing.png ├── fairness.png ├── fat-structure.jpg ├── fat.png ├── fetchandadd.png ├── ffs-problem1.png ├── ffs-problem2-app.png ├── ffs-problem2.png ├── file-cursor-and-fd.png ├── file-descriptor.png ├── image-20191224223715404.png ├── image-20191224232119039.png ├── image-20191224232454730.png ├── image-20191225111932456.png ├── image-20191225112350118.png ├── image-20191225112817297.png ├── image-20191225114915281.png ├── image-20191225132122834.png ├── image-20191225133118137.png ├── image-20191225133606125.png ├── image-20191225134325818.png ├── image-20191225141043930.png ├── image-20191225141117930.png ├── image-20191225151801078.png ├── image-20191225152755860.png ├── image-20191225152829065.png ├── image-20191225152930118.png ├── image-20191225153342630.png ├── inf-1.png ├── inf-2.png ├── inode-structure.png ├── iso-network.png ├── jitter-control.png ├── jorunaling-step.png ├── journaling.png ├── layer-package.png ├── link-differences.png ├── loadandstore.png ├── network-layer-connection-structure.png ├── nfs-structure.png ├── open-timeline.png ├── open-vs-fopen.png ├── package-window.png ├── pipeline-transmit.png ├── recursive-dns-look-up.png ├── replica-repair.png ├── rotation.png ├── routing-core.png ├── rpc-reply.png ├── rpc-request.png ├── rpc.png ├── simbolic-link-in-memory.png ├── simple-parity-check.png ├── testandset.png ├── three-line.png ├── topo-bgp.png └── voting.png /CSE复习笔记.md: -------------------------------------------------------------------------------- 1 | # CSE复习笔记 2 | 3 | ## File System 4 | 5 | ### FileSystem Layers 6 | 7 | #### Symbolic Link Layer 8 | 9 | ##### Two types of link(synonyms): 10 | ![abusolute-find-by-name](./images/simbolic-link-in-memory.png) 11 | 12 | > Add link “assignment” to “mail/new-assignment” 13 | > 14 | > - Hard link: 15 | > - no new file is created 16 | > - just add a binding between a string and an ***existing*** inode and the `refcnt` of the inode increased by 1 17 | > - if target file is deleted, the link is still valid 18 | > - Soft link 19 | > - a new file is created, the data is the string “mail/new-assignment” 20 | > - `refcnt` will not increase 21 | > - if target file is deleted, the link is invalid 22 | 23 | ![image-20191023135301201](./images/link-differences.png) 24 | 25 | ##### context change 26 | 27 | `cd soft-link` and then `cd .. ` will not change directory to target file’s upper directory. 28 | 29 | 30 | 如果你是新接入的设备，你将会在内存中记录一个inode（并不代表你这个设备里面也是inode组织形式的file system） 31 | 32 | 引入新的问题，如果我们想要在文件系统A里面做一个Link访问文件系统B的一个文件。实现这个功能的背景是： 33 | 34 | - Inode is different on other disks 35 | - supports to attach new disks to the name space 36 | 37 | 我们提出的两个方案： 38 | 39 | - make inodes unique all disks 40 | - create synonyms for the files on the other disks 41 | 42 | symbolic link的实现方式就是创建一个新的inode类型是link，我们读一个link类型的inode的时候，进行的操作是读取对应block的内容，内容即为我们指向的文件（夹）的absolute path 43 | 44 | #### Absolute path name layer 45 | 46 | ![abusolute-find-by-name](./images/abusolute-find-by-name.png) 47 | 48 | 这个inode table是书上这种集中式处理的方式里面的具体数据其实只展示了blocks这个部分，有关inode其他部分的信息只是没有在上图中展示出来。 49 | 50 | #### Path Name Layer 51 | 52 | #### Link 53 | 54 | 需要在inode层级上添加refcnt进行计数，当refcnt变为0时，则正式删除文件，即去除掉inode table中的记录。这个地方的link指hard link。每次unlink就是找到文件名对应的inode，然后通过inodetable找到具体的inode所在磁盘的offset，之后修改refcnt，并在该文件夹中消除该条entry。No Cycle for Link主要是类似于cpp中指针refcnt永远不会是0的情况。 55 | 56 | ##### renaming-1 57 | 58 | 1 UNLINK(to_name) 59 | 60 | 2 LINK(from_name) 61 | 62 | 3 UNLINK(from_name) 63 | 64 | 如果在1、2步中出现fail，等同于是把源文件给删了，但是tmp文件还是在的（这里的语境是Text Edit状态下），应该是可以进行恢复。 65 | 66 | ##### renaming-2 67 | 68 | 1 LINK(from_name, to_name) 69 | 70 | 2 UNLINK(from_name) 71 | 72 | 如果1和2中间出现fail，则会出现refcnt出现2。 73 | 74 | #### File Name Layer 75 | 76 | inode中添加一个type，是这一层的需求需要能够区分inode具体的数据的内容是什么，进行的读取的相应操作会不同，比如文件夹就是我进行dump之后直接写入，然后读出来之后进buffer后我会进行反序列化的过程(load/dump)。 77 | 78 | #### Inode Number Layer 79 | 80 | inode结构的索引，需要使用数字定位到具体磁盘的定位。存在在磁盘的前部。我们在lab中的实现inode是自增的，但是这样会爆炸，更好的方式是记录一个bitmap for inode number free。根目录的inode number 始终为1。 81 | 82 | #### File Layer 83 | 84 | ##### File Requirements 85 | 86 | 能存储超过一个block 87 | 88 | 可能会增长或减小 89 | 90 | 文件是一个block的数组 91 | 92 | 需要记录文件的长度 93 | 94 | ```c++ 95 | structure inode { 96 | integer block_numbers[N]; 97 | integer size; 98 | integer type; 99 | integer refcnt; 100 | } 101 | ``` 102 | 103 | 一个inode对应多个block 104 | 105 | ![inode-structure](./images/inode-structure.png) 106 | 107 | 一个inode假设是512Bit，指针是4Bit一个指针的话，能够指向的数据为(126+128+128*128) * 512Bit的数据，使用的组织结构的大小为(1+1+128) * 512 Bit 108 | 109 | inode table最普通的是说在磁盘的super block和bitmap for free block的后面的一块区域，可以通过inode number获取到inode在磁盘中的offset，我们也可以使用算法，让这个inode table不是一个中心式的，比如hash到我们的磁盘的各个部分，这样我们可做到inode和具体的数据block更加贴近，能够提升性能(locality) 110 | 111 | #### Block Layer 112 | 113 | 一个block number对应着一块block data，一个block data的大小是一定的。 114 | 115 | super block是在磁盘前面的一个部分主要是存储整个disk的一些metadata。 116 | 117 | kernel会在FS mount的时候读取superblock 118 | 119 | –What will happen if the block size is too small? What if too big? 120 | 121 | 主要是考虑到如果block size 太小了，会导致block number会很大，为了记录block number都会消耗掉很多的空间，且查询相对更消耗时间，但是资源利用率得到了提高，如果一个block size 过大super block会比较小，但是对于空间的利用率就没有什么保证。 122 | 123 | ### FAT(File Allocation Table) 124 | 125 | ![fat-structure](./images/fat-structure.jpg) 126 | 127 | **文件分配表：**FAT 文件系统的数据存储单元称为“簇”。簇的标准大小范围： 一个“簇”由一组连续的扇区组成，簇所包含的扇区个数必须是 2 的整数次幂， 如： 1、2、4、8、16、32 或 64 。 “簇” 的最大值为64个扇区，即32kb。 128 | 129 | **目录项：** FAT 文件系统内的每个文件和文件夹都被分配一个目录项， 这个目录项中记录了该文件或文件夹的，文件名、大小、创建时间、文件内容起始地址以及其他一些“元数据”，说明对应的文件的“起始簇号”。 130 | 131 | 如上图所示整体结构中的“FAT 区” 由文件分区所具有的两个“(大小、结构内容相同的)FAT 表”组成，“FAT 区”紧跟在“保留区”之后。“FAT 表” 用以描述 “数据区”中的数据存储单元的分配状态 以及 为文件或目录内容分配的存储单元的前后连接关系。 132 | 133 | 文件的元信息只包含name&size，并且这些源信息存储在文件夹中，文件夹也是一种文件，文件夹里面有很多的entries，entries可能是文件，文件就包含文件名和大小，也可能是子文件夹，但是size不知道是不是统计量。 134 | 135 | FAT不支持soft link和hard link，其上也不支持权限控制，就非常的简单。 136 | 137 | ### File Descriptor 138 | 139 | 使用File Descriptor的本因是在于我们要在操作系统通使用system call，比如write read等等，这个时候，我们需要有一个参数作为的连接操作系统和文件系统的桥梁。我们最开始会有两种选择： 140 | 141 | - 直接返回操作系统中对应的inode的指针 142 | - 直接返回所有的对应文件的所有block numbers 143 | 144 | 我们最终创建出File Descriptor这样的一个参数有以下两个原因： 145 | 146 | - 安全，用户不会如同一一样能够有机会访问到内核的数据结构。 147 | - 不会穿透让用户 直接操作文件系统，而是所有的文件操作均由操作系统代为处理。 148 | 149 | #### FD的使用场景 150 | ##### open() vs. fopen() 151 | 152 | ![image-20191023145403796](./images/open-vs-fopen.png) 153 | 154 | ##### cursor 155 | 156 | 1. 父子进程可以share cursor，通过父进程向子进程传递fd 157 | 2. 两个进程不share file cursor的是通过两个fd指向同一个文件来实现的。 158 | 159 | ##### fd_table & file_table 160 | 161 | 整个系统只有一个file_table，每个进程会有一个独立的fd_table，fd_table主要是记录map of fd to index of the file_table。 162 | 163 | 每一个process 都有自己的fd name space，即fd_table是process的context在进程间切换的时候会被切换掉，即如果在进程1中存在把fd=1 重定向到一个文件，切换到另一个继承进行cout，对应的文件并没有输入（仍然会打印到标准输出）。 164 | 165 | ![file-cursor-and-fd](./images/file-cursor-and-fd.png) 166 | 167 | #### 有关于atime mtime ctime的实验 168 | 169 | Time stamps 170 | 171 | - Last access (by READ) 172 | 173 | - Last modification (by WRITE) 174 | 175 | - Last change of inode (by LINK) 176 | 177 | atime对于ls第一次是可以的，第二次似乎在bash里面是有cache的，是不会再修改的了 178 | 179 | ### System Call OPEN READ CREATION 180 | 181 | ![FS-creation](./images/FS-creation.png) 182 | 183 | ![FS-open&write](./images/FS-open&write.png) 184 | 185 | **When writing, which order is preferred?** 186 | 187 | - Allocate new blocks, write new data, update size 188 | 189 | - Allocate new blocks, update size, write new data 190 | 191 | - Update size, allocate new blocks, write new data 192 | 193 | 第一个就是对的，因为如果size先给update了的话，一旦出现断电再恢复，就会发现读取到脏的数据，但是如果先allocate blocks然后断电了就会说只是磁盘自己内部有一块不见了。 194 | 195 | ##### 有关多进程删除文件 196 | 197 | 如果一个进程打开了某文件，但是另一个进程删除了该文件，这个时候unlink会删除掉文件夹里面的entry，inode的refcnt变为0，但是现在另一个进程手中的fd是对应的是inode（在file table）。 198 | 199 | ![FS-shadow](./images/FS-shadow.png) 200 | 201 | #### Polling & Interrupt 202 | 203 | Polling模式就是 OS 等待device做完操作之后再回到kernel态，这样浪费CPU太多的时间。 204 | 205 | Interrupt指 OS提交一个task，在task完成操作之后，device给OS发送一个信号量，OS开始处理相关的数据，这样会存在一个livelock的问题，CPU会经常进行interrupt而不会回到user-level process。 206 | 207 | 采用混合模式，默认情况下使用interrupt，在interrupt发生后，启用polling，直到timeout或者没有其他请求时切换回interrupt。 208 | 209 | #### Interrupt Coalescing for Optimization 210 | 211 | 这个方面是和上一个优化是相互呼应的，上面的优化是OS层面的，本段的优化是针对device层面的，会存在在准备触发一次Interrupt的情况下，先等待一个指定时间，再打包整个interrupt回去。 212 | 213 | #### DMA 214 | 215 | Memory和Disk的交互原来需要CPU持续操作，占用CPU时间，现在出现一块硬件，可以让Memory和Disk的交互经过DMA，不需要占用CPU时间。 216 | 217 | benefit： 218 | 219 | - 减轻CPU load的调用 220 | - 减少一次穿透 221 | - 扩大总线支持long message的优势 222 | - 摊销bus在protocol的overhead 223 | 224 | #### Methods of Device Interaction 225 | - PIO 通过in & out的汇编指令让CPU跟device进行交互，只能在kernel mode被调用 226 | - Memroy-mapped I/O，使用LOAD & STORE，可以在用户态被使用，比如mmap的调用 227 | 228 | #### 关于memory 229 | 230 | 出了cpu，所有的东西都是physical memory，我们原有的memory的physical memory被扩展到了system bus address（只是其中有一段是给了memory） 231 | 232 | #### IDE Protocol 233 | 234 | ![IDE-protocol](./images/IDE-protocol.png) 235 | 236 | ![IDE-protocol--2](./images/IDE-protocol--2.png) 237 | 238 | ### Bus 239 | 240 | **A set of wires** 241 | 242 | Comprising address, data, control lines that connect to a bus interface on each module 243 | 244 | **Broadcast link** 245 | 246 | Every module hears every message 247 | 248 | Bus address: identify the intended recipient, as the name 249 | 250 | **Bus arbitration protocol** 251 | 252 | Decide which module may send or receive message at any particular timea 253 | 254 | Bus arbiter (optional): a circuit to choose which modules can use the bus 255 | 256 | #### Bus Transaction 257 | 258 | 1. 源模块申请一个transaction，用于发送信息 259 | 2. 源模块设置目标模块的地址 260 | 3. 源模块发出READY信号通知其他模块 261 | 4. 目标模块发出ACKNOWLEDGE指令，在copy完数据之后，如果是同步的，只需要每个cycle去check 262 | 5. 源模块释放bus的独占 263 | 264 | #### Sync & Async 265 | 266 | 同步数据传输则目标和源用的同一个锁，异步数据传输指的是数据在传输，但是两块硬件仍自行工作。 267 | 268 | #### DMA运行方式 269 | 270 | ![DMA-step1](./images/DMA-step1.png) 271 | 272 | ![DMA-step2](./images/DMA-step2.png) 273 | 274 | ![DMA-step3](./images/DMA-step3.png) 275 | 276 | 整体的思维方式就是processor把map的任务下放到DMA，让Disk和Mmeory自行进行传输。 277 | 278 | ![IO-structure](./images/IO-structure.png) 279 | 280 | #### FFS 281 | 282 | ##### 第一层次优化 283 | 284 | 修改意见：增大block size 285 | 286 | ##### 第二层优化 287 | 288 | 修改意见：使用bitmap替代freelist，尝试对文件进行连续空间的分配，保留10%的空间不被使用，因为已经够碎片化了。为了应对文件的增长，我们为了预留了一个大的range(自定义) ，下一个文件就不要来占这个range，但是这样当前的磁盘使用率就很低。主要要解决的问题是，我们不知道这个文件在将来会有多大。我们首先会寻找相关的连续的空间，再看能不能去找到新range。 289 | 290 | ##### 第三层优化 291 | 292 | ### FileSystem Design 293 | 294 | #### Fast FS 295 | 296 | - 用bitmap代替freelist（可以快速查出连续块 297 | - 尽量为文件分配连续空间（减少碎片化 298 | - 保留10%的空间（阻止被迫地碎片存储的情况 299 | - skip sector positioning（减少寻道时间 300 | 301 | ##### block allocation 302 | 303 | ![image-20191023221515243](./images/ffs-problem1.png) 304 | 305 | ##### rotational delay 306 | 307 | 场景：（CPU controll）读一个块，做处理，再读其后紧跟的块，但同时，磁盘还在继续转动，导致第二次读取块数据时已经错过了块的起始位置。 308 | 309 | ![image-20191023221709055](./images/ffs-problem2.png) 310 | 311 | ![image-20191023221758231](./images/ffs-problem2-app.png) 312 | 313 | ##### cylinder group 314 | 315 | ![image-20191023222533836](./images/cylinder-group.png) 316 | 317 | - metadata和对应data的block更集中了，减少了寻道的时间 318 | - metadata分散，可以保证磁盘在物理损耗时还有部分metadata信息保留下来 319 | #### SMR 320 | 为了解决这个磁盘一直在转动，但是可能我们的指令没有传过来，导致磁头转过了我们要读的区域，只能再转一圈去读某个位置。为了解决这个问题，解决方法一是让文件稍微有一些间距，或者是在读整个一圈的时候，把整个一圈的数据都读出来，但是这个似乎可能出现一致性有一些问题。 321 | 322 | ##### 第四层优化 323 | 324 | header的信息并不是在靠近数据的地方，而是中心化的管理，在磁盘头（in special 325 | array in outermost cylinders ），这样读小文件，会存在读小文件，跳转两次，相对性能消耗就很大，可以把inode存储在于父目录一个或邻近的cylinder group。好处在于： 326 | 327 | 1. 对于小的目录，很可能在一个cylinder里面就可以读完所有的数据 328 | 2. file headers一般会很小，这样就能一次性读很多个文件信息 329 | 3. 因为是这种高内聚低耦合的情况，能够处理在磁盘损坏掉后，能够恢复很多的文件夹。 330 | 331 | ##### 第五层优化 332 | 333 | cylinder group就是一堆track的集合，我们以此为基础来进行磁盘的结构化建立。 334 | 335 | 优点： 336 | 337 | 1. 高效存储大小文件 338 | 2. 小文件大文件的locality都非常好 339 | 3. metadata and data都在邻近文件的位置 340 | 4. 没有整理碎片的必要 341 | 342 | 缺点： 343 | 344 | 1. 对于小文件非常的不友好，利用率太低 345 | 2. –Inefficient encoding when file is mostly contiguous on disk 346 | 3. 需要10%~20%的空间去预防碎片化 347 | 348 | 对于极小的文件，我们可以选择的优化是文件直接存在其inode中，或者我们为了提高利用率，我们也可以把小文件存进block的下一级，fragment里面去。对于大文件我们也可以对最后的残余放在本文件的其他残余的block中的fragment中（不够的还是单开一个block） 349 | 350 | ## Durability 351 | 352 | ### MTTF MTTR MTBF 353 | 354 | MTTF: mean time to failure 355 | 356 | MTTR: mean time to repair 357 | 358 | MTBF: mean time between failure 359 | 360 | MTBF = MTTF + MTTR 361 | 362 | Availability 是用多少个9来表示 363 | 364 | MTTF 和 Availability 是相互正交的两个概念，可以 MTTF 很大而 Availability 很小，也可以 MTTF 很小而 Availability 很大。 365 | 366 | #### Redundancy 367 | 368 | ##### forward error correction(正向纠错) 369 | 370 | 在传输前进行编码，之后接收端不依靠传输端进行解码验证 371 | 372 | ##### hamming distance 373 | 374 | hamming距离这个操作是用于衡量一个编码方式的能力的。 375 | 376 | 如果一种编码方式，其能够编码出的正确编码（一定是数量有限的），两两之间的hamming distance为n，则该编码方式具有第n种纠错和查错的能力。 377 | 378 | 例如n=2，则可以查错1位（两位都跳变是不能被查到的），n=3可以纠错一位，n=4可以查两位错，纠一位错。 379 | 380 | #### Voting 381 | 382 | ![voting](./images/voting.png) 383 | 384 | TMR可以提升reliability。IF R(T) = 0.999 TMR's R(T) = 0.999997 385 | 386 | MTTF会随着冗余的数量增大而减小。 387 | 388 | replica的数量变得过大，也是没有效率的因为下式： 389 | 390 | ![MTTF-system](./images/MTTF-system.png) 391 | 392 | #### replica repair 393 | 394 | ![replica-repair](./images/replica-repair.png) 395 | 396 | 当replica恢复的时候，我们需要作出抉择来确定恢复到什么阶段，如果是1和7就不需要额外的操作，2、3恢复到old，5、6恢复到7，而4比较特殊，这里选择是恢复到7。 397 | 398 | #### Durable Storage 399 | 400 | ##### RAID 1 401 | 402 | 在另一块独立的磁盘上进行备份，能够容忍一个磁盘出现错误。 403 | 404 | 优化：周期性的检查，进行损坏部分的修复。 405 | 406 | ##### RAID 4 407 | 408 | 有N个数据盘，每个数据盘存储的数据并不相同，此外，存在一个盘存储其余盘相同条进行异或之后的数据，这样一个盘的数据损坏也是可以进行修复的。（有其他方式知道具体是哪个盘坏了，这个可能也需要checksum的帮助，我们现阶段的情况只能是知道坏了）。性能的角度上来讲我们可以把一个文件分再前面的多个盘中，这样文件读写的性能就会有所提升，但是写纠错盘的I/O瓶颈会出现。 409 | 410 | ##### RAID 5 411 | 412 | 在RAID 4的基础上，将纠错盘分散到数据盘中，这样就不需要害怕纠错盘丢失，也没有纠错盘的I/O瓶颈限制。 413 | 414 | ### Recovering FS Metadata From Crash 415 | 416 | #### Synchronous metadata update + fsck 417 | 418 | FS 能够保证的： 419 | 420 | - Internal consistency（内部的一致性） 421 | 422 | - No dangling references（没有悬空的指向，原子性） 423 | 424 | - Inode and block free list contain only used (not using) items （一个block不会既存在在 inode 中又出现在free list中） 425 | 426 | - Unique name in one directory, etc.（文件夹下不会出现同名文件） 427 | 428 | FS的工作： 429 | 430 | 1. Check superblock 431 | 432 | 检查一下super block里面是否存在错误，比如 file system size 是否大于已经分配出去的block的总大小，如果有问题我们可以启用备用的superblock。 433 | 434 | 2. Check free blocks 435 | 436 | 从inode和block bitmap这两个角度check下block是否存在问题，并且在 inode bitmap上也做相应的check看是否存在一个inode存在，但是inode bitmap没有修改。 437 | 438 | 3. Check inode states 439 | 440 | 检查inode 的type和具体的文件类型对数据进行解析，看是否有误。这个地方应该会有精妙的设计去把这个疑似错误相关的内容的inode都给清除掉。 441 | 442 | 4. Check inode links 443 | 444 | 检查link count(指hard link)，如果count mismatches，就修复inode，如果是一个inode存在，但是refcnt = 0，此时则可以进行放进lost+found，实质refcnt = 1 445 | 446 | 5. Check duplicates 447 | 448 | 检查是否有两个inode使用了同一个block（前面只是将这个block不会即出现在inode中又出现在free list中） 449 | 450 | 6. Check bad blocks 451 | 452 | 比如block的地址out of range。这个出错就会让fscheck把指针删了。 453 | 454 | 7. Check directories 455 | 456 | The only file that fsck know more semantic。要保证. 和 .. 需要出现在前面。 457 | 458 | 检查文件夹link是否出现环，检查文件夹下是否出现同名文件 459 | 460 | 这里要注意一个点就是我们如果是使用那种把inode打散到磁盘内部了，我们fscheck的性能是会下降的，但是我们fscheck这个操作会被用到的次数就很少，不需要考虑fscheck的性能。 461 | 462 | ##### right order of synchronous writes 463 | 464 | File creation 465 | 466 | 1. mark inode as allocated 467 | 468 | 2. create directory entry 469 | 470 | File deletion 471 | 472 | 1. erase directory entry 473 | 474 | 2. erase inode addrs[], mark as free 475 | 476 | 3. mark blocks free 477 | 478 | ##### disk buffer 479 | 480 | disk告诉OS他已经做完的时候，实质上是把磁盘的相关数据写入到了disk buffer中，也没有被持久化，也没有顺序。 481 | 482 | 我们解决这个问题的方法主要是两种，第一种是直接disable掉buffer，另一种就是强制进行flush操作（但是flush也可能不会被执行）。 483 | 484 | #### Soft update 485 | 486 | 487 | 488 | #### Logging 489 | 490 | ![jorunaling-step](./images/jorunaling-step.png) 491 | 492 | 我们需要持久化到硬盘上的数据主要就是Data、Journaling Metadata、Journal Commit、Checkpointing。我们可以使用checksum的技术，相当于是给commit添加一个可验证编号，如果checksum出现问题，则会选择在恢复的时候丢弃掉相应的block。这样就可以让Data、 Journaling Metadata、Journal Commit三者之间是可以同步无序的。 493 | 494 | 第二次flush是不可避免的是因为如果M不写入，我们也可以从Journal中恢复如果M在之这些之前被写入到磁盘中，就会出现一个幻影文件，我们journal里面也没法检测到。 495 | 496 | ### NFS(Network File System) 497 | 498 | NFS的出现主要是一个machine不够用的情况（更多用户，更多的文件），需要进行多台机器进行联动。 499 | 500 | ### RPC(Remote Procedure Call) RMI in java 501 | 502 | ![rpc](./images/rpc.png) 503 | 504 | 曾经我们的结构是Client和Service两者在同一个系统下，不存在网络调用。只是多了个stub，stub做整体处理，对操作系统无感。 505 | 506 | client stub的主要任务是将function call转换为请求（符合RPC协议），并且等待返回，进行解包。 507 | 508 | service stub的主要任务是等待发包，从request中解析出参数，调用server本地的函数，并获取返回值，将返回值写入到response中，返回response给client。 509 | 510 | 需要额外添加的参数和行为： 511 | 512 | 1. service ID 513 | 2. service parameter 514 | 515 | 我们在lab的源码上发现了我们的rpc是基于socket实现的，socket按道理是在osi第五层会话层里面的实现。 516 | 517 | 既然RPC的客户端认为自己是在调用本地对象。那么传输层使用的是TCP/UDP还是HTTP协议，又或者是一些其他的网络协议它就不需要关心了。既然网络协议对其透明，那么调用过程中，使用的是哪一种网络IO模型调用者也不需要关心。因为他仅仅只是想实现这样一套调用方式。 518 | 519 | 我们的lab和ppt上使用的是socket实现udp传输，自行设置Xid和相关参数（就是你相关body里面的信息可自定义化） 520 | 521 | ![rpc-request](./images/rpc-request.png) 522 | 523 | ![rpc-reply](./images/rpc-reply.png) 524 | 525 | #### RPC System Components 526 | 527 | 1. RPC信息和数据类型的标准 528 | 529 | 2. 序列化和反序列化的库 530 | 531 | 3. stub generator or RPC compiler去生成stub 532 | 533 | 4. Server Framework 534 | 535 | 实现方式可以有很多种，第一是对每一个到来的request创建一个新线程，或者是在一开始就初始化线程池，在线程池前面准备好MQ。或者是最简单的实现单线程 serial execution（串行执行） 536 | 537 | 5. Client Framework 538 | 539 | client端需要维护Xid，有可能多次的调用是使用的是同一个socket，经常会需要处理超时和重试。 540 | 541 | 6. Binding 542 | 543 | 这个地方我们用的都是IP基础之上的协议，其实我们考虑在这个地方做负载均衡似乎也是可以的。 544 | 545 | ### NFS 546 | 547 | #### goal 548 | 549 | 1. 对现有的应用兼容 550 | 2. 独立于OS 551 | 3. 容易部署 552 | 553 | ![NFS](./images/NFS.png) 554 | 555 | File Handler 包含3个部分： 556 | 557 | 1. File System Identifier 558 | 2. inode number 559 | 3. generation number 560 | 561 | 为什么不适用path name 存在于handle中？ 562 | 563 | 个人认为有一定的性能原因，首先是这样在对应的NFS中仍旧需要去查找一遍对应，这非常消耗性能。其次是我们对于相对应的文件没有办法知道句柄的数量多少，另外其他的client对文件夹，文件进行了相对应的修改，会导致另外的client不可用，但是存inode不存在这样的情况。 564 | 565 | #### Stateless on NFS Server 566 | 567 | 尽可能的让用户端保存相应的状态，我们的NFS server唯独需要记录的soft state是 reply cache。 568 | 569 | #### NFS case study 570 | 571 | ##### rename after open 572 | 573 | 不会有影响，因为我们这边fh记录的是inode，与unix系统的行为是一致的。 574 | 575 | ##### delete after open 576 | 577 | 在之前的笔记中也提到，这样的情况发生在unix上是会让另一个进程读取老文件的。但是我们这边是使用了一个–Generation number来补足这个的inode描述性不足的问题，行为就是如果这个文件已经被删除了，你就不能再读了。 578 | 579 | ##### NFS cache 580 | 581 | NFS因为存在网络调用，网络层的cache是必不可少的。能够有效的减少latency，另一方面，我们也需要关注cache coherence。 582 | 583 | ##### close-to-open consistency 584 | 585 | 当我们打开文件时，我们需要获取到last modification time，并将该项时间与cache中的记录进行比较，当关闭的时候，讲cache写入到server中。 586 | 587 | ![nfs-structure](./images/nfs-structure.png) 588 | 589 | #### RPC带来的新问题 590 | 591 | RPC减少了fate sharing但是带来的新问题是latency变高且会因为网络的问题造成no response的新问题。 592 | 593 | 针对response，RPC有如下三种方式处理错误： 594 | 595 | - At Least Once 596 | 597 | client至少接收到一次返回，如果没有收到则选择一直发送请求。 598 | 599 | - At Most Once 600 | 601 | 服务端的服务是幂等的，服务端只会提供最多一次返回 602 | 603 | - Exactly Once 604 | 605 | 只问一次，也只返回一次 606 | 607 | ##### Lanuage Support 608 | 609 | 例如全局变量和数据结构中存在指针。 610 | 611 | ##### Security Consideration 612 | 613 | client和server端都需要进行authentication，引入了一切网络通信中存在的危险 。 614 | 615 | ![GFS](./images/GFS.png) 616 | 617 | 一主多从，metadata都在master上，相关的data都在slave上 618 | 619 | ![GFS-read](./images/GFS-read.png) 620 | 621 | ![GFS-write](./images/GFS-write.png) 622 | 623 | ![GFS-write-in-secondary](./images/GFS-write-in-secondary.png) 624 | 625 | 注意这个5-9的步骤是可以异步执行的。如果出现write fail的情况，client会进行retry 626 | 627 | client就相关元信息是与master进行交互，具体的信息交互是直接与chunkserver进行交互。 628 | 629 | ##### GFS Master 630 | 631 | - client在数据上不会与master交互 632 | - master会将chunckserver的位置发送给client（注意这里其实我们可以选择做成master直接redirect到具体的chunk server上，这样是会少一次调用，但是反代的流量大概率会从master走，这从流量的角度就不好了，这个也是GFS的主要思想） 633 | - 存在shadow master去解决fault tolerance 634 | - metadata是存在于内存中的，master会监控monitor chunk location，通过chunk server主动发的heartbeat 635 | - GFS中不存在inode、smlinks和hard link 636 | - 一个文件、文件夹被当做一个node在table中。 637 | 638 | ##### Chunck Server 639 | 640 | - 一个chunk的大小是64MB，这样metadata比较小 641 | - Chunk需要进行多备份 642 | 643 | ##### Single Master（指的不是master只有一台机子，是只有一个中心，管理了所有的数据，数据没有sharding） 644 | 645 | - master的流量不大，具体读写的流量不会经过master因此master没有那么容易崩溃 646 | - master也存在replica机制 647 | - shadow master 可以提供read-only的服务，与上一条合起来就是一个主从关系（但是这个启用仅仅是在master崩了的时候） 648 | 649 | #### Fault Tolerance and Diagnosis 650 | 651 | - log下有关metadata所有的change 652 | - 周期性checkpoints 653 | - log和checkpoints被同步到replica 654 | 655 | #### Data Integrity 656 | 657 | - 每64KB就为一个chunk，会有一个32的checksum 658 | - 在每一次read或者write都会check一遍 659 | 660 | ## Network 661 | 662 | ### CDN 663 | 664 | 网络上的内容能够在整个Internet上有多备份，能够做到让资源更加贴近用户 665 | 666 | #### DNS 667 | 668 | 根据用户的网络环境，动态的通过hostname这一层次将用户的request redirect到邻近用户的IP。 669 | 670 | #### Binding IP and Domain Name 671 | 672 | 一个hostname可以对应多个value，一个value可以对应多个hostname。 673 | 674 | #### Name Server 675 | 676 | 层级化 677 | 678 | /etc/hosts可以在本地进行记录单条的DNS解析 679 | 680 | /etc/resolv.conf可以添加Name Server 681 | 682 | ![recursive-dns-look-up](./images/recursive-dns-look-up.png) 683 | 684 | 我们对于Name Server可以设置cache，cache的时间长短(TTL)是一个trade off，如果TTL设置较大，则域名解析的稳定性和速度将得到极大的提高，但是对应的，在修改完A记录的时候，这个传播速度就讲会非常的慢。如果TTL设置得较小，则旧域名的记录将迅速过期，但是域名解析的稳定性和速度就不稳定。 685 | 686 | 对于IP地址相对固定，或短期内不会变更IP地址的用户来说TTL值设置的大些如几个小时或更大些为宜。调大TTL值可以显著的提高域名的解析稳定性和速度。而对于近期有计划变更IP地址的用户需要提前把TTL值改小，以便使缓存在世界各地DNS服务器上的旧域名记录迅速过期，等IP地址固定下来后再把TTL值改大。 687 | 688 | #### 层次结构化的意义 689 | 690 | - 层次化同样代表着责任的划分（上层一般不会记录和cache一个孙子记录，只会让你去找儿子记录） 691 | - 每一个区域都是代表着一个小的部分 692 | - 层次结构限制了模块之间的交互 693 | 694 | - 去中心化 695 | 696 | ### DNS设计的优点 697 | 698 | - 全局命名，不存在上下文 699 | - 可扩展性强，在性能和管理上 700 | - 高容错 701 | 702 | ### DNS设计的缺点 703 | 704 | - 关于根节点的控制应该在谁手里 705 | - 根节点的大量负载，以及潜在的DDOS攻击的风险 706 | - 安全，用户只能100%相信返回值，并且对于域名解析的合法性很难做到保证（至少在这一层上）。 707 | 708 | #### DNS扩大攻击 709 | 710 | ![DNS-Amplification](./images/DNS-Amplification.jpg) 711 | 712 | 主要的杠杆是，发送这个DNS解析请求的数据低于DNS的回复量，这样就能进行DDOS攻击。 713 | 714 | ### Packet Encapsulation 715 | 716 | ![layer-package](./images/layer-package.png) 717 | 718 | 这个图主要讲的是层次与包之间的关系 719 | 720 | ### LINK LAYER 721 | 722 | ![three-line](./images/three-line.png) 723 | 724 | 三线protocol。 725 | 726 | 1. A places data on data line 727 | 728 | 2. A changes value on the ready line 729 | 730 | B sees the ready line change, reads value on the data line, then changes the acknowledge line 731 | 732 | #### Isochronous & Asynchronous 733 | 734 | ![iso-network](./images/iso-network.png) 735 | 736 | ![async-network](./images/async-network.png) 737 | 738 | #### DEmutiplexing 739 | 740 | ![demultiplexing](./images/demultiplexing.png) 741 | 742 | 确定一帧的方式：使用7个1bit的1来进行间隔，如果遇到有6个1，则将在其后添加0 743 | 744 | 在遇到错误时的处理方式： 745 | 746 | 1. 利用足够的redundancy进行纠错 747 | 2. 让对方重新将这一帧发过来（注意这里是第二层，发过来的只有帧，不是TCP里面的包的try） 748 | 3. 丢弃掉该帧 749 | 4. 以上全部 750 | 751 | 差错纠错的方式： 752 | 753 | ![simple-parity-check](./images/simple-parity-check.png) 754 | 755 | ![4-7check](./images/4-7check.png) 756 | 757 | ### Network Layer 758 | 759 | If it cannot dispatch, may discard a packet. 网络是没有那么稳定的，一定要考虑到网络的不稳定性。 760 | 761 | #### Routing 762 | 763 | ![routing-core](./images/routing-core.png) 764 | 765 | 我们前面在GFS的时候是有提到过Control & Data，GFS用一种方式将Control & Data两者进行解耦，在我们路由里面，现在Control & Data是在一起的，因为就是用这些数据来进行规则制定达到控制转发的目的。 766 | 767 | ##### Packet Forwarding 768 | 769 | 这里要回到之前的图，IP HEADER到底加的内容如下： 770 | 771 | ```c++ 772 | structure packet 773 | bit_string source 774 | bit_string destination 775 | bit_string end_protocol 776 | bit_string payload 777 | ``` 778 | 779 | ![network-layer-connection-structure](./images/network-layer-connection-structure.png) 780 | 781 | 以NetWork Layer为主视角，NETWORK_HANDLE是其中最为重要的。send数据写入相关信息，送出到LINK SEND。收到数据先找到下一跳到何方（找不到就直接丢包，或者是TTL到了就丢包，不然压力太大，这也是后面讲TCP处理堵塞的基础），更新header checksum（因为我们改了包头），如果重点并不在我，则寻找下一跳，向后运输，否则直接给到上层。 782 | 783 | ##### NAT 784 | 785 | nat主要是建立vpc和公网之间的关系，主要解决的是IP不够用的难题。 786 | 787 | Router between private & public network 788 | 789 | Send: modify source address to temp public address 790 | 791 | Receive: modify back by looking mapping table 792 | 793 | Limitations 794 | 795 | Some end-to-end protocols place address in payloads 796 | 797 | The translator may become the bottleneck 798 | 799 | **What if two private network merge?** 800 | 801 | NAT是要按包来记录的，NAT这张表会非常频繁的进行变更，所以对应的硬件要比较好。 802 | 803 | 而且NAT将网络层和传输层紧耦合，我们NAT要处理port和IP两个部分的问题 804 | 805 | ##### Ethernet Mapping 806 | 807 | ![IP-spec-HEADER](.\images\IP-spec-HEADER.png) 808 | 809 | 注意这里已经到了Link Layer，我们这里的地址是48位的mac地址，而非IP地址。我们的IP地址是在data中的。我们的mac地址会被记录到交换机中 810 | 811 | ###### 内网进行交互 812 | 813 | 不需要forwarding，发送直接的传输到内网的对应的网卡上。 814 | 815 | ###### 内网与外网交互 816 | 817 | 当所有的地址都对不上时，这个时候需要找到我们的router，router会找到出去的另一跳。 818 | 819 | ##### IP <=> MAC ——ARP (Address Resolution Protocol) 820 | 821 | 1. 发送端需要查看自己的ARP表，查看是否存在接收端的ARP表项。 822 | 2. 如果找不到接收端的MAC地址，将以广播的方式发送一个ARP请求报文，其中带有发送端的IP地址，接收端收到相关的IP地址后与自己的IP地址进行比较，最终会返回自己的mac地址，让发送方进行登记。 823 | 3. 如果接收端并不跟自己在同一个网段中，则这个时候我们的路由器会主动站出来发送自己的MAC地址给发送端（ARP欺骗） 824 | 825 | ##### ARP欺骗攻击 826 | 827 | ![arp-hacker](./images/arp-hacker.png) 828 | 829 | 主要是通过广播的方式，让A中的ARP发生变化，让流量转移到hacker上。 830 | 831 | ##### middle attack 832 | 833 | ![arp-middle-attack](./images/arp-middle-attack.png) 834 | 835 | ##### routing control 836 | 837 | routing control只是为了跟上级结构routing进行区分，我们这里主要是讨论control plane。 838 | 839 | 1. Link-State 840 | 841 | 一个节点为更新自己的距离表，开始向自己的邻居发送advertisement，整个遍历的过程就是求解Dijkstra最短路算法的过程，整个算法的性能与节点数量成正比（整个图的各个点到点的最短路径都又求了一遍，不仅仅是A）。 842 | 843 | 2. Distanc-vector Routing 844 | 845 | 只会更新来自自己邻居的信息，不会再进一步进行扩展，不会记录非常远的节点的相关数据 846 | 847 | ![inf-1](./images/inf-1.png) 848 | 849 | 我们接收neighbor发来的路径信息，并进行更新，如果简单的直接更新，就会发生上述的情况，虽然最后的结果是对的，但是这其中经历了一个不断上升的过程，INF的值会比较大的情况下，这样的时间会很多。 850 | 851 | ![inf-2](./images/inf-2.png) 852 | 853 | 较最简单的更新方式，我们将neighbor路过我们的相关信息给筛除掉（我是最了解我自己的），这样就会直接更新到C INF的状态，但是这只是避免了2-node loop如果loop包含三个节点及其以上，就没法处理，仍旧会出现INF问题。 854 | 855 | ##### Path Vector 856 | 857 | 和distance vector很像，但是我们需要记录下更多的信息，即路径，由于记录下了路径，则出现环的情况不会出现，每一次更新都会检查路径。 858 | 859 | 出现有节点消失的情况，我们可以使用的策略是，当我们的邻居没有对advertising进行回应的时候，就可以去除掉所有与该节点有关的路径。 860 | 861 | Path Vector的问题在于每一个新加入的node都需要自己的unique address，这和我们的VPC是有冲突的，其次我们的path vector的大小是与node数量正相关的。 862 | 863 | 这个地方这个path vector的算法会运行非常多次直到网络稳定，一个新加的节点会逐渐被周围的节点所认识，一个节点离开网络的信息也会慢慢被传播到整个网络 864 | 865 | 我们就需要进行Hierarchy，则出现了网段的概念，这让整个网络变得更加的复杂。 866 | 867 | ##### Border Gateway Protocol 868 | 869 | BGP是层次化结构的产物，因为在某个网段里面，就跟我们的域名一样，我们在网络上的路由进行的hierarchy，则责任义务和权力也进行了hierarchy，这个地方，不管什么目的，我们的每个网段与其他网段之间的关系希望是一个动态可由自己控制的关系。 870 | 871 | ![customers&peers](./images/customers&peers.png) 872 | 873 | peer之间的路是不需要用钱买通的。 874 | 875 | ![topo-bgp](./images/topo-bgp.png) 876 | 877 | 这里主要强调的是，我们的BGP是允许上述结构存在，即Y不花钱就能搭上X的便车，但这个从金钱关系上是说不通的。 878 | 879 | BGP是不安全的，因为如果有人说自己能去google但是不能去，大家就会相信其能去google，但是他其实不能，就劫持了所有去google的流量。 880 | 881 | ### End-To-End Layer 882 | 883 | #### Assurance of at-least-once delivery 884 | 至少要保证数据能够收到一次，或者就是服务真的崩溃了，就给app返回error。 885 | 886 | RTT = to_time + process_time + back_time 887 | 888 | Dilema：我们不知道到底是data就没有给，还是说ACK没有收到 889 | 890 | - Send packet with **nonce** 891 | 892 | - Sender keeps a copy of the packet 893 | 894 | - Resend if timeout before receiving acknowledge 895 | 896 | - Receiver acknowledges a packet with its **nonce** 897 | 898 | #### Timeout问题 899 | 900 | ##### Fixed Timer 901 | 902 | 固定一个timeout时间，这个是最简单，也是最死板的做法。比如wisconsin大学的时间服务器由于client的处理方式是如果没收到就1秒钟发一次，直到收到了之后就变成1天患者一小时发一次。由于压力值过大，retry导致time server接收到的请求一直增长，导致服务器崩溃，而且在时间同步这个服务的协议中，对应的厂商没有实现完整的SNTP，其中的go away机制没有被实现。 903 | 904 | ##### Adaptive Timer 905 | 906 | 每次都将RTT扩大150%，或者呈指数级增长。主要是要根据现在的情况动态的计算RTT和Timeout。 907 | 908 | ```c 909 | rtt_avg = a*rtt_sample + (1-a)*rtt_avg; /* a = 1/8 */ 910 | dev = absolute(rtt_sample – rtt_avg); 911 | rtt_dev = b*dev + (1-b)*rtt_dev; /* b = 1/4 */ 912 | Timeout = rtt_avg + 4*rtt_dev 913 | 914 | ``` 915 | 916 | 917 | 918 | ##### NAK (Negative AcKnowledgment) 919 | 920 | sender取消掉timer，receiver方承受更大的责任 921 | 922 | 1. receiver 告诉sender他什么信息没有收到 923 | 2. receiver可以对收到的信息进行计数 924 | 925 | （如果是真一个包都没收到，就肯定是丢包了，sender会自动重发的） 926 | 927 | 总归就是得有一端来主动说，数据没了。 928 | 929 | 对于收到的包是乱序的问题，我们解决的方式为： 930 | 931 | **Solution-1**: Receiver only ACK in order packets, discards others 932 | 933 | Waste of bandwidth 934 | 935 | **Solution-2**: ACK every packet and hold early packets in buffer, release the buffer when all in order 936 | 937 | Need using large buffer when waiting for a bad packet 938 | 939 | **Solution-3**: Combine the two above 940 | 941 | Discard if buffer is full 942 | 943 | New problem: how much buffer? 944 | 945 | **Speedup for common case** 946 | 947 | –NAK to avoid timeout 948 | 949 | –If NAKs are causing duplicates, stop NAKs 950 | 951 | #### Assurance of At-most-once Delivery 952 | At-least-once delivery：就是之前类似nonce的方式，倾向于发起第二次request 953 | 954 | At-most-once-delivery：在receiver设置table来记录nonce，但这个表会存在无限增长和永不删除的情况，也可以让这个application能够忍受两次返回。 955 | 956 | #### Assurance of Data Integrity 957 | sender：add checksum 958 | 959 | receiver：recalculates the checksum 960 | 961 | 注意每一个层级的checksum都是有不同用途的，我们在Link Layer会存在说不相信网络传输吗，这里的checksum是不信任memory copying这个过程。 962 | 963 | #### Segments and Reassembly of Long Messages 964 | 因为MTU的大小在有时候会比一个包小很多（1500），因此我们在发包的时候Link Layer会分包，我们在发的时候会附带信息(message id & segment id)。这个fragment的层级化就和我们FFS里面的fragment的出现是比较相像的。这个地方如果开始使用fragment的概念，就会存在fragment层级的管理，首先是我们可以乱序。 965 | 966 | 这个地方会有说法是，我们如何从二层的丢帧走到四层的丢包，我们二层如果丢帧了，作为receiver，我们传到第四层就会不会返回ACK。 967 | 968 | 如果out of order我们的解决方案： 969 | 970 | 1. 仍旧按order进行收 971 | 2. 我们对收到的fragment都写入buffer，这样会需要一个非常大的buffer 972 | 3. 将上述两者进行组合 973 | 974 | #### TCP 四次挥手 975 | 976 | 1. Alice sends close request to Bob with stream record ID 977 | 978 | 2. Bob checks and agrees, sends a close ACK 979 | 980 | 3. Alice receives ACK, turn off sender, discard record 981 | 982 | 4. Alice sends "all done" to Bob 983 | 984 | 5. Bob receives "all done" and discard stream record 985 | 986 | #### Assurance of Jitter Control 987 | 对于电影或者视频，我们对于一些丢包是并不在意的，我们对于是否能及时看到比较在意，所以我们要保证delivery time，我们会对收到的segment都写入到buffer 988 | 989 | ![jitter-control](./images/jitter-control.png) 990 | 991 | #### Assurance of Authenticity and Privacy 992 | ssl use public key encrypt message, which is an identify for reader 993 | 994 | private key in server can decrypt the message and then encrypt response 995 | 996 | response can be encrypt with public key by client 997 | 998 | #### End-to-end Performance 999 | trade off between complexity and performance 1000 | 1001 | 如果我们按照之前segment进行发包，我们会发现这个性能就非常的慢，于是我们这个fragment发包的情况变成pipeline执行的方式。 1002 | 1003 | ![pipeline-transmit](./images/pipeline-transmit.png) 1004 | 1005 | ![package-window](./images/package-window.png) 1006 | 1007 | fix window => slide window 1008 | 1009 | #### Congestion Control 1010 | 1011 | Increase congestion window slowly 1012 | 1013 | If no drops -> no congestion yet 1014 | 1015 | **If a drop occurs -> decrease congestion window quickly** 1016 | 1017 | 1. Slow start: one packet at first, then double until 1018 | 1019 | ​ Sender reaches the window size suggested by the receiver 1020 | 1021 | ​ All the available data has been dispatched 1022 | 1023 | ​ Sender detects that a packet it sent has been discarded 1024 | 1025 | 2. Duplicate ACK 1026 | 1027 | When receiver gets an out-of-order packet, it sends back a duplicate of latest ACK 1028 | 1029 | 3. Equilibrium 1030 | 1031 | ​ Additive increase & multiplicative decrease 1032 | 1033 | 4. Restart, after waiting a short time 1034 | 1035 | 1036 | ##### WindowSize的shedding 1037 | 1038 | 为了性能： 1039 | 1040 | window size ≥ round-trip time × bottleneck data rate 1041 | 1042 | 不等式右边其实就是规定了一个segment现在的最大大小，因为我们肯定是希望能够在一个RTT内就收到一次ACK，这样就能正常运行，那一个RTT内我们能收到的数据就是右式的大小，如果window size比这个值小，是一定能够保证在一个RTT内收到ACK的，所以我们为了提升性能，我们可以把window size 调得大些。 1043 | 1044 | 为了解决拥堵： 1045 | 1046 | window size ≤ min(RTT x bottleneck data rate, Receiver buffer) 1047 | 1048 | 正如上文所说，window size 变得比较小是为了减小同时发出去的包，尽可能的保证在包收到的情况下进行其他操作。 1049 | 1050 | AIMD 1051 | 1052 | ![TCP-Retrofitting](./images/TCP-Retrofitting.png) 1053 | 1054 | ![fairness](./images/fairness.png) 1055 | 1056 | -------------------------------------------------------------------------------- /Cse note.md: -------------------------------------------------------------------------------- 1 | # Cse note 2 | ## Transaction 3 | ### CAP Theory 4 | * Consistency,Availability,Partition tolerance 5 | * P通常是一个事实 6 | * AP or CP 7 | * C和A并不是0或1的选择 8 | 9 | ### Abstractions of The Transaction 10 | 11 | ![image-20191224223715404](./images/abstractions.png) 12 | 13 | 14 | 15 | ### All or nothing 16 | 17 | Atomicity 18 | #### Shadow copy 19 | * 需要在每层软件和硬件都有一个commit point，如果中途crash还是会导致非原子操作的问题 20 | * 主要思想是only make one write to current/live copy of data 21 | * 对多个文件或文件夹的操作难以实现；仅仅是修改一小部分也需要拷贝整个文件；一次只能执行一个操作；无法在多核或多个磁盘上work 22 | #### Logging 23 | * Operations: begin / write variable/ read variable/ commit/ abort 24 | * Performance: 25 | * `write` is probably good because sequential writes and twice writes 26 | * `read` is terrible because need to scan the log for every read 27 | * `recovery` is instantaneous 28 | 29 | ##### Performance optimization 30 | 31 | - Add `cell storage`: 32 | 33 | Improving `read`.`recovery` requires scanning the entire log. 34 | 35 | ![image-20191224223715404](./images/image-20191224223715404.png) 36 | 37 | Write-ahead-log protocol, this is log the update before installing it. 38 | 39 | - Add cache for cell install: 40 | 41 | Improving `write` and `read`.Need a redo phase in addition to an undo phase in recovery. 42 | 43 | - Truncate the log(add checkpoint): (一对CKPT来确定一个完整的transaction) 44 | 45 | ![image-20191224232119039](./images/image-20191224232119039.png) 46 | 47 | ![image-20191224232454730](./images/image-20191224232454730.png) 48 | 49 | - External synchronous I/O: 50 | 51 | Flush when something externally visible happens, e.g., print network sending, serial port outcome, etc. 52 | 53 | ### Before or after 54 | 55 | In the design above, there is a problem that a write can be seen by other transactions before its COMMIT. 56 | 57 | Transactions provide atomicity and isolation while not hindering performance. 58 | 59 | Eventually, we also want transaction-based systems to be **distributed**: to run across multiple machines. 60 | 61 | #### Serializability 62 | 63 | - Final-state serializability 64 | - Conflict serializability 65 | 66 | ![image-20191225111932456](./images/image-20191225111932456.png) 67 | 68 | ![image-20191225112350118](./images/image-20191225112350118.png) 69 | 70 | Conflict Graph 是 **有向图** . 71 | 72 | - View serializability 73 | 74 | ![image-20191225112817297](./images/image-20191225112817297.png) 75 | 76 | Final-state serializability $\supset$ View serializability $\supset$ Conflict serializability 77 | 78 | Schedules that are view serializable but not conflict serializable involve **blind writes** : 79 | 80 | > Blind writes: writes that are ultimately not read, which are not common in practice 81 | 82 | Basically: conflict serializability has practical benefits. 83 | 84 | How to generate **conflict serializability** schedules? 85 | 86 | > Pessimistic methods: global lock, 2-phase locking 87 | > 88 | > Optimistic methods: OCC 89 | 90 | #### 2PL(Two-Phase Locking) 91 | 92 | Global lock: one transcation a time $\Rightarrow$ Simple Locking: acquire a lock for every shared data in advance and release locks only after commit or abort $\Rightarrow$ 2PL 93 | 94 | ![image-20191225114915281](./images/image-20191225114915281.png) 95 | 96 | Optimization: Read-write Locks(one write lock and multiple read locks for each variable) $\to$ `REPEATABLE READ` 97 | 98 | Problem: 2PL can result in deadlock. 99 | 100 | Solutions: global ordering on locks or take advantage of atomicity and abort one of the transactions. 101 | 102 | #### OCC(Optimistic Concurrency Control) 103 | 104 | **乐观并发控制**（又名“**乐观锁**”，Optimistic Concurrency Control，缩写“OCC”）是一种并发控制的方法。它假设多用户并发的事务在处理时不会彼此互相影响，各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务又修改了该数据。如果其他事务有更新的话，正在提交的事务会进行回滚。 105 | 106 | ![image-20191225132122834](./images/image-20191225132122834.png) 107 | 108 | ![image-20191225133118137](./images/image-20191225133118137.png) 109 | 110 | T2已经commit，所以如果T1commit成功，那么，从commit的角度看T2先于T1，从最后效果的角度看T1先于T2 111 | 112 | #### BCC(Balanced CC) 113 | 114 | ![image-20191225133606125](./images/image-20191225133606125.png) 115 | 116 | ![image-20191225134325818](./images/image-20191225134325818.png) 117 | 118 | ## Lock & Memory Model 119 | 120 | ### Implementing the lock 121 | 122 | - software solution: 123 | - Using load and store instructions only 124 | - Dekker’s & Peterson’s Algorithms 125 | - hardware solution: 126 | - RSM: read-set-memory 127 | - TestAndSet, CompareAndSwap, LoadLinked+StoreConditional, FetchAndAdd 128 | 129 | Peterson’s algorithms rely on atomicity of load and store, which does not hold on today’s hardware that has **relaxed memory consistency models**. 130 | 131 | ### Memory consistency models 132 | 133 | - strict consistency ( A read gets the latest write value ) 134 | - sequential consistency 135 | - Sequential consistency is **weaker** than strict consistency. Allow "memory write lag". But require write propagate at the same time 136 | - cache coherence is a locally consistent view. E.g., for local variable x or y, all CPUs see the same order; but for (x,y), different CPUs may see different orders. 137 | - sequential consistency is a globally consistent view 138 | 139 | ![image-20191225141043930](./images/image-20191225141043930.png) 140 | 141 | - processor consistency ( consider the network latency ) 142 | - Writes done by a single processor are received by all other processors in the issue order 143 | - But writes from different processors may be seen in a different order by different processors 144 | 145 | ![image-20191225141117930](./images/image-20191225141117930.png) 146 | 147 | ### Atomic instructions 148 | 149 | - TestAndSet 150 | 151 | ```c 152 | 1 int TestAndSet(int *old_ptr, int new) { 153 | 2 int old = *old_ptr; // fetch old value at old_ptr 154 | 3 *old_ptr = new; // store 'new' into old_ptr 155 | 4 return old; // return the old value 156 | 5 } 157 | ``` 158 | 159 | 160 | 161 | - CompareAndSwap 162 | 163 | ```c 164 | 1 int CompareAndSwap(int *ptr, int expected, int new) { 165 | 2 int actual = *ptr; 166 | 3 if (actual == expected) 167 | 4 *ptr = new; 168 | 5 return actual; 169 | 6 } 170 | 171 | ``` 172 | 173 | 174 | 175 | - LoadLinked+StoreConditional 176 | 177 | ```c 178 | 1 int LoadLinked(int *ptr) { 179 | 2 return *ptr; 180 | 3 } 181 | 4 182 | 5 int StoreConditional(int *ptr, int value) { 183 | 6 if (no one has updated *ptr since the LoadLinked to this address) { 184 | 7 *ptr = value; 185 | 8 return 1; // success! 186 | 9 } else { 187 | 10 return 0; // failed to update 188 | 11 } 189 | 12 } 190 | 191 | ``` 192 | 193 | 194 | 195 | - FetchAndAdd 196 | 197 | ```c 198 | 1 int FetchAndAdd(int *ptr) { 199 | 2 int old = *ptr; 200 | 3 *ptr = old + 1; 201 | 4 return old; 202 | 5 } 203 | 204 | ``` 205 | 206 | 207 | 208 | ### Lock performance 209 | 210 | - coarse-grained lock 211 | - fine-grained lock $\Rightarrow$ deadlock/livelock 212 | - pessimistically lock ordering 213 | - optimmistically backing out, setting timer expiration or cycle detection 214 | 215 | ### Methods for Solving Deadlock 216 | 217 | - **Lock ordering (pessimistic)** 218 | - Number the locks uniquely 219 | - Require transactions acquire locks in order 220 | - Problem: some app may not predict all of the locks they need before acquiring the first one 221 | - **Backing out (optimistic)** 222 | - Allow acquire locks in any order 223 | - If it encounters an already-acquired lock with an number lower than one it has previously acquired itself, then 224 | - UNDO: Back up to release its higher-numbered locks 225 | - Wait for the lower-numbered lock and REDO 226 | - **Timer expiration (optimistic)** 227 | - Set a timer at begin_transaction, abort if timeout 228 | - If still no progress, another one may abort 229 | - Problem: how to chose the interval? 230 | - **Cycle detection (optimistic)** 231 | - Maintain a wait-for-graph in the lock manager 232 | - Shows owner and waiting ones 233 | - Check when transaction tries to acquire a lock 234 | - Prevent cycle (deadlock) 235 | - Select some cycle member to be a victim 236 | 237 | Livelock & Deadlock ( refer to 阿月 ) 238 | 239 | Livelock：整天不做正事，导致正事永远做不完 240 | Deadlock：“你先把枪放下！”“你放我就放！”“你放我才放！”（无限套娃 241 | 242 | ## Thread and Condition Variable 243 | 244 | ![image-20191225151801078](./images/image-20191225151801078.png) 245 | 246 | ### schedule 247 | 248 | ![image-20191225152755860](./images/image-20191225152755860.png) 249 | 250 | ![image-20191225152829065](./images/image-20191225152829065.png) 251 | 252 | ![image-20191225152930118](./images/image-20191225152930118.png) 253 | 254 | When create a new thread, the stack of the thread must be initialized to include YIELD(), and push the return address to the middle of YIELD(), so that when after return, the new thread will first release the lock, just as the previous slide. Then return again to the start_procedure (by pushing the address to the stack too). 255 | 256 | ![image-20191225153342630](./images/image-20191225153342630.png) 257 | 258 | ## Distributed Transaction 259 | 260 | ### Two phase commit 261 | 262 | - phase-1: preparation/voting 263 | - lower-layer transactions either aborts or tentatively committed 264 | - higher-layer transaction evaluates lower situation 265 | - phase-2: commitment 266 | - if top-layer, then COMMIT or ABORT 267 | - if nested itself, then become tentatively committed 268 | 269 | -------------------------------------------------------------------------------- /images/4-7check.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/4-7check.png -------------------------------------------------------------------------------- /images/DMA-step1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/DMA-step1.png -------------------------------------------------------------------------------- /images/DMA-step2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/DMA-step2.png -------------------------------------------------------------------------------- /images/DMA-step3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/DMA-step3.png -------------------------------------------------------------------------------- /images/DNS-Amplification.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/DNS-Amplification.jpg -------------------------------------------------------------------------------- /images/FS-creation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/FS-creation.png -------------------------------------------------------------------------------- /images/FS-open&write.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/FS-open&write.png -------------------------------------------------------------------------------- /images/FS-shadow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/FS-shadow.png -------------------------------------------------------------------------------- /images/GFS-read.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/GFS-read.png -------------------------------------------------------------------------------- /images/GFS-write-in-secondary.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/GFS-write-in-secondary.png -------------------------------------------------------------------------------- /images/GFS-write.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/GFS-write.png -------------------------------------------------------------------------------- /images/GFS.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/GFS.png -------------------------------------------------------------------------------- /images/IDE-protocol--2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/IDE-protocol--2.png -------------------------------------------------------------------------------- /images/IDE-protocol.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/IDE-protocol.png -------------------------------------------------------------------------------- /images/IO-structure.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/IO-structure.png -------------------------------------------------------------------------------- /images/IP-spec-HEADER.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/IP-spec-HEADER.png -------------------------------------------------------------------------------- /images/MTTF-system.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/MTTF-system.png -------------------------------------------------------------------------------- /images/NFS.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/NFS.png -------------------------------------------------------------------------------- /images/RAID4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/RAID4.png -------------------------------------------------------------------------------- /images/RAID5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/RAID5.png -------------------------------------------------------------------------------- /images/TCP-Retrofitting.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/TCP-Retrofitting.png -------------------------------------------------------------------------------- /images/abstractions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/abstractions.png -------------------------------------------------------------------------------- /images/abusolute-find-by-name.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/abusolute-find-by-name.png -------------------------------------------------------------------------------- /images/arp-hacker.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/arp-hacker.png -------------------------------------------------------------------------------- /images/arp-middle-attack.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/arp-middle-attack.png -------------------------------------------------------------------------------- /images/async-network.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/async-network.png -------------------------------------------------------------------------------- /images/compareandswap.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/compareandswap.png -------------------------------------------------------------------------------- /images/create-timeline.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/create-timeline.png -------------------------------------------------------------------------------- /images/customers&peers.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/customers&peers.png -------------------------------------------------------------------------------- /images/cylinder-group.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/cylinder-group.png -------------------------------------------------------------------------------- /images/demultiplexing.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/demultiplexing.png -------------------------------------------------------------------------------- /images/fairness.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/fairness.png -------------------------------------------------------------------------------- /images/fat-structure.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/fat-structure.jpg -------------------------------------------------------------------------------- /images/fat.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/fat.png -------------------------------------------------------------------------------- /images/fetchandadd.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/fetchandadd.png -------------------------------------------------------------------------------- /images/ffs-problem1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/ffs-problem1.png -------------------------------------------------------------------------------- /images/ffs-problem2-app.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/ffs-problem2-app.png -------------------------------------------------------------------------------- /images/ffs-problem2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/ffs-problem2.png -------------------------------------------------------------------------------- /images/file-cursor-and-fd.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/file-cursor-and-fd.png -------------------------------------------------------------------------------- /images/file-descriptor.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/file-descriptor.png -------------------------------------------------------------------------------- /images/image-20191224223715404.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/image-20191224223715404.png -------------------------------------------------------------------------------- /images/image-20191224232119039.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/image-20191224232119039.png -------------------------------------------------------------------------------- /images/image-20191224232454730.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/image-20191224232454730.png -------------------------------------------------------------------------------- /images/image-20191225111932456.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/image-20191225111932456.png -------------------------------------------------------------------------------- /images/image-20191225112350118.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/image-20191225112350118.png -------------------------------------------------------------------------------- /images/image-20191225112817297.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/image-20191225112817297.png -------------------------------------------------------------------------------- /images/image-20191225114915281.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/image-20191225114915281.png -------------------------------------------------------------------------------- /images/image-20191225132122834.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/image-20191225132122834.png -------------------------------------------------------------------------------- /images/image-20191225133118137.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/image-20191225133118137.png -------------------------------------------------------------------------------- /images/image-20191225133606125.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/image-20191225133606125.png -------------------------------------------------------------------------------- /images/image-20191225134325818.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/image-20191225134325818.png -------------------------------------------------------------------------------- /images/image-20191225141043930.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/image-20191225141043930.png -------------------------------------------------------------------------------- /images/image-20191225141117930.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/image-20191225141117930.png -------------------------------------------------------------------------------- /images/image-20191225151801078.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/image-20191225151801078.png -------------------------------------------------------------------------------- /images/image-20191225152755860.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/image-20191225152755860.png -------------------------------------------------------------------------------- /images/image-20191225152829065.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/image-20191225152829065.png -------------------------------------------------------------------------------- /images/image-20191225152930118.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/image-20191225152930118.png -------------------------------------------------------------------------------- /images/image-20191225153342630.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/image-20191225153342630.png -------------------------------------------------------------------------------- /images/inf-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/inf-1.png -------------------------------------------------------------------------------- /images/inf-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/inf-2.png -------------------------------------------------------------------------------- /images/inode-structure.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/inode-structure.png -------------------------------------------------------------------------------- /images/iso-network.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/iso-network.png -------------------------------------------------------------------------------- /images/jitter-control.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/jitter-control.png -------------------------------------------------------------------------------- /images/jorunaling-step.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/jorunaling-step.png -------------------------------------------------------------------------------- /images/journaling.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/journaling.png -------------------------------------------------------------------------------- /images/layer-package.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/layer-package.png -------------------------------------------------------------------------------- /images/link-differences.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/link-differences.png -------------------------------------------------------------------------------- /images/loadandstore.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/loadandstore.png -------------------------------------------------------------------------------- /images/network-layer-connection-structure.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/network-layer-connection-structure.png -------------------------------------------------------------------------------- /images/nfs-structure.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/nfs-structure.png -------------------------------------------------------------------------------- /images/open-timeline.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/open-timeline.png -------------------------------------------------------------------------------- /images/open-vs-fopen.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/open-vs-fopen.png -------------------------------------------------------------------------------- /images/package-window.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/package-window.png -------------------------------------------------------------------------------- /images/pipeline-transmit.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/pipeline-transmit.png -------------------------------------------------------------------------------- /images/recursive-dns-look-up.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/recursive-dns-look-up.png -------------------------------------------------------------------------------- /images/replica-repair.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/replica-repair.png -------------------------------------------------------------------------------- /images/rotation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/rotation.png -------------------------------------------------------------------------------- /images/routing-core.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/routing-core.png -------------------------------------------------------------------------------- /images/rpc-reply.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/rpc-reply.png -------------------------------------------------------------------------------- /images/rpc-request.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/rpc-request.png -------------------------------------------------------------------------------- /images/rpc.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/rpc.png -------------------------------------------------------------------------------- /images/simbolic-link-in-memory.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/simbolic-link-in-memory.png -------------------------------------------------------------------------------- /images/simple-parity-check.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/simple-parity-check.png -------------------------------------------------------------------------------- /images/testandset.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/testandset.png -------------------------------------------------------------------------------- /images/three-line.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/three-line.png -------------------------------------------------------------------------------- /images/topo-bgp.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/topo-bgp.png -------------------------------------------------------------------------------- /images/voting.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/2019SE419/CSEReviewNote/2191fb30e3382f7049c95083ccbecaa525ecd40d/images/voting.png --------------------------------------------------------------------------------