lesson-03.html 23.1 KB
   1
   2
   3
   4
   5
   6
   7
   8
   9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  30
  31
  32
  33
  34
  35
  36
  37
  38
  39
  40
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58
  59
  60
  61
  62
  63
  64
  65
  66
  67
  68
  69
  70
  71
  72
  73
  74
  75
  76
  77
  78
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114
 115
 116
 117
 118
 119
 120
 121
 122
 123
 124
 125
 126
 127
 128
 129
 130
 131
 132
 133
 134
 135
 136
 137
 138
 139
 140
 141
 142
 143
 144
 145
 146
 147
 148
 149
 150
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167
 168
 169
 170
 171
 172
 173
 174
 175
 176
 177
 178
 179
 180
 181
 182
 183
 184
 185
 186
 187
 188
 189
 190
 191
 192
 193
 194
 195
 196
 197
 198
 199
 200
 201
 202
 203
 204
 205
 206
 207
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226
 227
 228
 229
 230
 231
 232
 233
 234
 235
 236
 237
 238
 239
 240
 241
 242
 243
 244
 245
 246
 247
 248
 249
 250
 251
 252
 253
 254
 255
 256
 257
 258
 259
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282
 283
 284
 285
 286
 287
 288
 289
 290
 291
 292
 293
 294
 295
 296
 297
 298
 299
 300
 301
 302
 303
 304
 305
 306
 307
 308
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338
 339
 340
 341
 342
 343
 344
 345
 346
 347
 348
 349
 350
 351
 352
 353
 354
 355
 356
 357
 358
 359
 360
 361
 362
 363
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394
 395
 396
 397
 398
 399
 400
 401
 402
 403
 404
 405
 406
 407
 408
 409
 410
 411
 412
 413
 414
 415
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450
 451
 452
 453
 454
 455
 456
 457
 458
 459
 460
 461
 462
 463
 464
 465
 466
 467
 468
 469
 470
 471
 472
 473
 474
 475
 476
 477
 478
 479
 480
 481
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506
 507
 508
 509
 510
 511
 512
 513
 514
 515
 516
 517
 518
 519
 520
 521
 522
 523
 524
 525
 526
 527
 528
 529
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562
 563
 564
 565
 566
 567
 568
 569
 570
 571
 572
 573
 574
 575
 576
 577
 578
 579
 580
 581
 582
 583
 584
 585
 586
 587
 588
 589
 590
 591
 592
 593
 594
 595
 596
 597
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618
 619
 620
 621
 622
 623
 624
 625
 626
 627
 628
 629
 630
 631
 632
 633
 634
 635
 636
 637
 638
 639
 640
 641
 642
 643
 644
 645
 646
 647
 648
 649
 650
 651
 652
 653
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
<title>Computer Networks (3)</title>
<meta name="cours-n" content="3">

<meta name="author" content="Rémi Emonet">
<meta name="venue" content="DWA M1 WI/MLDM">
<meta name="date" content="2017">
<meta name="affiliation" content="Université Jean Monnet − Laboratoire Hubert Curien">
<style type="text/css">
.inlineimages img {display: inline !important; }
.slide .above {position:absolute; left: 20px; top: 20px; width: 760px; height: 460px; text-align:center;}
.above {z-index: 100 !important;}
tt {border: 1px solid #DDD;}
</style>

<!--
<script src="deck.js/extensions/includedeck/load.js"></script>
<script src="extensions/slides-dev.js"></script>
-->
<script src="extensions/deck-packed.js"></script>
<script src="extensions/slides.js"></script>
<script>go()</script>
</head>

<body>

<div class="deck-container">

<div class="deck-loading-splash" style="background: black; color: chartreuse;"><span class="vcenter" style="font-size: 30px; font-family: Arial; ">Please wait, while our marmots are preparing the hot chocolate…</span></div>

<section class="smart">

# @chunk: chunks/title.md

# @chunk: chunks/objectives.md

# Reminder {no-print}

## Projects {no-print}
- Subject
- peer to peer file sharing, kind of bittorent
- Phase 1 : group creation
- group and team creation, sending an email
- name and github username (of each member)
- chosen programming language for the project
- deadline: **Tuesday, January 17th, 22h** // then I invite
- Phase 2
- understanding of the subject
- creation of a protocol specification (version 1)
- Phase 3 {libyli}
- implementation
- test
- documentation of possible evolutions


<!-- plan -->
## Part 2: Application Layer{#plan overview}
@SVG: media/stack-index.svg 100px 400px {svg floatright app margin-left-minus-100}

- Goal{shaded}
- protocols: general principles and existing protocols
- sockets: programming and services from the transport layer
- Overview
- Principles of distributed applications {it1}
// and interactions with the transport layer
- HTTP and the web {it2}
- FTP: file transfer {it3}
- Electronic mail {it4}
- DNS: name resolution and more {it5}
- P2P Applications (peer to peer) {it6}
- Network programming: using sockets {it7}
# @copy:#plan



<!-- ======== HTTP ======== -->
# @copy:#plan: %+class:inred: .it2

# HTTP and the Web {no-print}

## A Page Web in a Browser
- Concepts
- web page = set of objects
// references in the HTML page
- type of objects{slide}
- HTML source, CSS, javascript
- image: PNG, JPEG, …
- multimedia file: mp3, avi, webm, …
- Java applet, flash, …
- URL, uniform resource locator {slide}
- example: <tt>http://wikipedia.fr/Fichiers/LogoWikipedia.png</tt>
- <tt>http</tt>: protocol
- <tt>wikipedia.fr</tt>: hosts
- <tt>/Fichiers/LogoWikipedia.png</tt>: path
- « web address » (when <tt>http://</tt>)

## HTTP: Introduction
- HTTP: hypertext transfer protocol
- Application layer protocol
- Client-server architecture{slide}
- client process
- web browser
- queries, receives and displays web objects
// in the sense of the preceding slide
- server process
- web server
- send objects in response to requests
- Use of TCP{slide}
- listen on port 80 (by default)
// rq: server = the who listens, client = ...
- Stateless protocol (without state){slide}
- the HTTP server (the protocol) does not keep information on the client
- independent requests
// still, can store on top of HTTP, easier to implement
## HTTP Connections {libyli}
// over TCP but 2 approaches

- Non-persistent connection
- a TCP connection per request
- opening and closing at each request
- Persistent connection
- opening a TCP connection
- sending multiple HTTP requests/responses on this connection
- need to keep the connection open
// may have a cost for the server (threads, etc)
- Example of HTTP session over TCP{slide}
- @anim: .svg | #tcpinit | #tcpack | #get | #reply

@SVG: media/part2/simple-http-with-tcp-handshake.svg 800px 200px {svg}


## How long does it take to display <br/>a web page from a server in Mexico?{question bottom}
- Round-trip time Saint-Étienne &lrarr; Mexico: 180ms
- The HTML page references // can show some source of a page
- 5 images, 3 javascript files
- 2 stylesheets (CSS)
- Objects are supposed to be small (~ 1 kB each)

@SVG: media/part2/simple-http-with-tcp-handshake.svg 250px 200px {svg,floatright}

## What solution can you imagine <br/>to reduce the delay to display <br/>the web page from Mexico?{question}

## Example HTTP Request {libyli}
- HTTP defines requests and responses
- Example request
// it is plain-text

<pre>
<span>GET</span> /index.php HTTP/1.1
<span>Host</span>: wikipedia.fr
<span>User-Agent</span>: Mozilla/5.0 (X11; Ubuntu; …) Gecko/20100101 Firefox/26.0
<span>Accept</span>: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
<span>Accept-Language</span>: en-US,en;q=0.5
<span>Accept-Encoding</span>: gzip, deflate
<span>Connection</span>: keep-alive
</pre>

- @anim: %+class:inred:pre span:nth-of-type(1)
- Request line: method (GET, POST, HEAD, …), path, version{slide}
- @anim: %+class:inred:pre span:nth-of-type(2), pre span:nth-of-type(3)
- Header lines
- «name» : «value»
- @anim: %+class:inred:pre span:nth-of-type(4), pre span:nth-of-type(5), pre span:nth-of-type(6)
- content negotiation{slide}
- @anim: %+class:inred:pre span:nth-of-type(7)
- connection persistence {slide anim-continue}
- …{slide}

## Format of an HTTP (pseudo-grammar)
- «» &rarr; (a space)
- «newline» &rarr; \r \n
- «request» &rarr; «req-line» «header-line»* «newline» «body»
- «req-line» &rarr; «method» «» «path» «» «http-version» «newline»
- «method» &rarr; GET | POST | HEAD | PUT | DELETE
- «header-line» &rarr; «name» : «value»

## Sending More Data in an HTTP Request
- Typical use
- data to send from the client to the server
- values from a form (filled by the user)
- file to upload
- Use of the POST method{slide}
- send data in the «body»
- Encoding data in the URL (with GET){slide}
- for short data only (forms only)
- adding new elements in the URL
- <tt style="font-size: 80%">http://en.wikipedia.org/w/index.php<span class="red">?search=kitten&title=Special%3ASearch</span></tt>
- <tt>search = kitten</tt>
- <tt>title = Special:Search</tt>

## Format of an HTTP Response
- «request» &rarr; «req-line» «header-line»* «newline» «body»<br/>{shaded}
- «req-line» &rarr; «method» «» «path» «» «http-version» «newline»{shaded}
- «response» &rarr; «resp-line» «header-line»* «newline» «body»
- «resp-line» &rarr; «http-version» «» «code» «» «message» «newline»
- «code» &rarr; 200 | 404 | …
- «message» &rarr; OK | Not Found | …
// just a description for humans, free
- HTTP <i>status codes</i>{slide}
- <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html">http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html</a>
- 200 OK: object is in the «body»
- 301 Moved Permanently: object changed address
- a header "Location:" gives the new location
- 400 Bad Request: the server does not understand the request
- 404 Not Found: the object is not found on the server
- 505 HTTP Version Not Supported

## {image-full bottom-left darkened /black-bg /no-status} // not a very technical course on admin
<div class="img" style="background-image: url('media/part2/301-cat.jpg')" data-attribution="" data-attribution-content="" data-scale="">
</div>
## {image-full bottom-left darkened /black-bg /no-status} // not a very technical course on admin
<div class="img" style="background-image: url('media/part2/500-cat.jpg')" data-attribution="" data-attribution-content="" data-scale="">
</div>

## HTTP Cookies // might try telnet {libyli}
<img class="floatright" src="media/part2/cookies.jpg" style="width:200px">

- Store a state
- inside the client
- on the server initiative
- sent back to the server at every request (by the client)
- Usage
- save preferences (language, skin, …)
- user tracking {slide}
- the server generates a unique ID
- the server tracks all page hits from this ID
- the server profiles the client
- &rArr; product recommendation, session persistence, …

## HTTP <i>Cookies</i>
@SVG: media/part2/cookie-sequence.svg 800px 400px {svg}

- @anim: #get | #setcookie | #c1 | #c2 | #get2 | #c3 | #hasdb | #dbcreate | #dbadd1 | #later | #get3 + #c4 | #dbadd2 | #dbanalyze

## HTTP <i>Cookies</i>: summary
<img class="floatright cmonster" style="clear:right; width: 200px;" src="media/part2/cookie-monster.jpg">

- Uses of cookies
- user preferences
- authentication
- shopping basket (e-commerce)
- user session
// e.g. webmail
- HTTP is stateless {slide}
- the “cookies protocol” is at the application level
- clients and server(s) maintains a state together (cookie)
- the HTTP message contains the state
- Privacy issues?{slide anim-continue}
- the user is tracked without nowing // now, in France, have to warn
- all the browsing history
// even before login
- user profiles get sold
- price policy
// plane tickets can increase progressively to make you buy
- information mixing between very different sites
- widgets (buttons like +1, like, analytics, etc) on so many sites
- @anim: .cmonster

# _ {no-print}

## What problem/solution do you see <br/>in the network below?{question bottom}
// autre chose, problème

@SVG: media/part2/cache-local.svg 800px 200px {svg}


## Web Caching
@SVG: media/part2/cache-local.svg 700px 230px {svg centered}

- @anim: #r1g | #r1m | -#hidecache
- Local cache Server {slide}
- on the local network
- “intercepts” web communications to internet
- saves web objects webs coming from outside
- Advantages{slide}
- reduced data transfers with the outside
- reduced costs
- average latency also reduced

## Web Caching: protocol, conditional GET
@SVG: media/part2/cache-web-sequence.svg 700px 400px {svg centered}

- @anim: #r1 | #r2 | #r3 | #dbsave | #r4 | #r5 | #dbget | #r6
- @anim: #later | #rl1 | #rl2 | #rl3 | #rl4 | #rl5
- HTTP caching protocol{slide}
- header: <tt>If-not-modified-since</tt>
- response: <tt>304 Not Modified</tt> or <tt>200 OK</tt>
- @anim: #lightdb | #rmore1 | #rmore2 | #rmore3 | #rmoredbsave





<!-- FTP -->
# @copy:#plan: %+class:inred: .it3

# FTP: file transfer {no-print}

## FTP: RFC959
- Goal
- transferring files to/from a server
- from hard drive to hard drive
- bi-directional
- Principles{slide}
- 2 networking ports
- port 21: control connection
- port 20: intermittent data connection
- &rarr; out-of-band commands (separate from the data)
- the server is stateful, it stores for each client{slide}
- the current folder
- the logical link between data and control connections
- 2 modes for *data* connections{slide}
- passive (PASV), the client connects to the server
- active (PORT), the server connects to the client
// less useful (and problematic)

## FTP: Examples of requests and responses // plain-text

- Requests
- <tt>USER bob</tt>
- <tt>PASS secret</tt>
- <tt>LIST</tt>
- <tt>RETR file.txt</tt>
- <tt>STOR new.txt</tt>
- <tt>PASV</tt>
- <tt>QUIT</tt>
- …
- Responses{slide}
- <tt>331 Username OK, password required</tt>
- <tt>125 Data connection already open; transfer starting</tt>
- <tt>425 Can't open data connection</tt>
- <tt>452 Error writing file</tt>
- <tt>221 Goodbye</tt>
- …


<!-- SMTP, POP, IMAP -->
# @copy:#plan: %+class:inred: .it4

# Electronic Mail {no-print}

## Architecture for Electronic Mails
@SVG: media/part2/email-servers.svg 800px 370px {svg}

- @anim: #s1 | #c1s | #s2 | #c2s | #s3 | #s4 + #c4s | #smtp + .smtp | #popimap + .imap
- SMTP Protocol: sending emails{smtp}
- POP and IMAP Protocols: reading emails{imap}
- User-Agent: mail client, webmail, etc{slide}

## Sending Electronic Mails
@SVG: media/part2/email-servers-sending.svg 750px 370px {svg centered}

- @anim: #m1 | #send1 | -#send1 + -#m1 + #m2 | #send2 | -#send2 + -#m2 + #m3 | #send3 | -#send3 + -#m3 + #m4
- @anim: #m1 + #send1 + #m2 + #send2 + #m3 + #send3

## SMTP Protocol: RFC2821
- Goal
- sending emails
- asynchronous messages
- Principles and limitations{slide}
- use of TCP
- use of port 25 (by default)
- request/response protocol
- direct transfer to the destination server {slide}
- a server responsible for each domain{slide}
// no routing between mail servers (privacy)
- message {slide}
- sender
- recipient
- content
- headers
- 7-bits ASCII{slide}

## Example of SMTP Session
- C -> S: client (crepes.fr) to server (hamburger.edu)
// chocking ! no password

<pre class="slide">
S->C: 220 hamburger.edu
C->S: HELO crepes.fr
S->C: 250 Hello crepes.fr, pleased to meet you

C->S: MAIL FROM: &lt;alice@crepes.fr>
S->C: 250 alice@crepes.fr... Sender ok
C->S: RCPT TO: &lt;bob@hamburger.edu>
S->C: 250 bob@hamburger.edu ... Recipient ok
C->S: DATA
S->C: 354 Enter mail, end with "." on a line by itself
C->S: How do you do? Well?
C->S: Networking is amazing!
C->S: .
S->C: 250 Message accepted for delivery

C->S: QUIT
S->C: 221 hamburger.edu closing connection</pre>

- "HELO", "MAIL FROM", "RCPT TO", "DATA"{slide}
- end with a line containing only with "."{slide}

## SMTP: format for « DATA »
- «message» &rarr; «header» «newline» «body»
// ligne vide
- «newline» &rarr; \r \n
- «header» : RFC 822
- ex : <tt>To: ...</tt>
- ex : <tt>From: ...</tt>
- ex : <tt>Subject: ...</tt>
- different from MAIL FROM, RCPT TP, etc
- «body» : the message in ASCII

## Accessing Electronic Mails
- SMTP: sending{shaded}
- POP3 <i>Post Office Protocol</i>, RFC 1939{slide}
- access to the inbox
- downloads and deletes, or, downloads and keep
- minimal protocol (list, get), plain-text protocol
- IMAP <i>Internet Mail Access Protocol</i>, RFC 1730{slide}
- conservation of messages on the server
- creation of folders (and sub-folders)
- organization of messages: tags, etc
- plain-text protocol
- Webmail over HTTP, diverse range of features{slide}
- Common properties {slide}
- require authentication
- versions with secured transport (SMTPS, IMAPS, …)
// no clear-text password, different ports with S




<!-- DNS -->
# @copy:#plan: %+class:inred: .it5

# DNS: name resolution <br/> (and more) {no-print}

## DNS: Global View
- DNS{col2}
- Domain Name System
- name resolution
- IP(s) &rlarr; name(s)
- acts as a distributed database{c2a}
- many servers
- hierarchical organization
- at the core of internet{c2b}
- very useful
- implemented in the “application” layer
// note used underneath, so complexity pushed to the application side
- Goal:<br/> wikipedia.fr &rlarr; 78.109.84.114{col1}
- Us, humans{col1 slide}
- first name, last name
- passport number
- social security number // or equivalent
- driving license number
- …
- Internet hosts{col1 slide}
- IP address
- for the network layer
// to have efficient routing
- ex: 78.109.84.114
- “name”
- for the human users
- ex: wikipedia.fr
- @anim: .col2 | .c2a | .c2b

## DNS: Services and Distributed Architecture
- DNS Services
- name resolution (name &rarr; IP)
- name aliases (pseudonym){slide}
- canonical name
- list of aliases
- mail server alias{slide}
- ex: message for <tt>bob@blabla.com</tt>  sent to  <tt>mymailserv.blabla.com</tt>
// to have a simpler name
- load balancing{slide}
- <tt>www.google.fr</tt> &rarr; <tt style="font-size:80%">74.125.132.99, 74.125.132.147, 74.125.132.104, …</tt>
- Distributed architecture with caching{slide}
- multiple distributed servers
- fault resistance
- maintainability
- scalability (traffic volume)
- reduces latency

## DNS: Hierarchical Organization
@SVG: media/part2/dns-hierarchy.svg 700px 200px {svg centered}

- Hierarchy
- Root DNS servers (global)
- TLD (Top-Level Domain) servers (ex of TLD: <tt>.fr</tt>)
- Authoritative DNS servers
- gives authoritative answers for a given domain
- server in a company, university, ISP, …
- List of TLDs : https://www.iana.org/domains/root/db/
- each TLD has its own rules // e.g. .cat a page in catalan

## DNS: DNS Root Servers {no-print}
<img src="media/part2/root-servers.jpg" width="800px">

## DNS: Resolution Principle
- Resolving <tt>fr.wikipedia.org</tt>
- asks a root server <br/> what is an address for a TLD server <tt>.org</tt>{slide}
- ask the TLD server <br/> what is the address of an authoritative server for <tt>wikipedia.org</tt>{slide}
- ask the authoritative server <br/> what is the address for <tt>fr.wikipedia.org</tt>{slide}

@SVG: media/part2/dns-hierarchy.svg 700px 200px {svg centered}

## DNS Request: recursive vs/and iterative
@SVG: media/part2/dns-queries.svg 400px 350px {svg floatleft noobj2}

@SVG: media/part2/dns-queries.svg 400px 350px {svg floatleft noobj1 rec}

- Typical set of requests
- “recursive” request to a local server
- “iterative” requests by the local server
- Requests in all-recursive (seldom used){rec}
- @anim: #st1 | #st23 | #st45 | #st67 | #st8
- @anim: .rec

## DNS and Caching
- Caching done by servers
- as soon as a server discovers a DNS record (e.g., nom&rlarr;IP)
- this record is cached
- ex: addresses of TLD servers cached by local servers
// &rarr; no more request to roots
- fixed caching duration (set by the authority): TTL (Time To Live)
// in seconds (stackoverflow.com: 300s, 5min)
- update delay, possibility of “errors”, due to caching
- Protocol to notify of updates{slide}
- to limit this update delay
- RFC 2136

## 4 Different Types DNS Records
- DNS = database of DNS Resource Record (RR)
- format of a RR: (type, name, value, ttl) // actual order is name,value,type,ttl ?
- TTL: Time To Live
- Messages in the DNS protocol: binary format{slide}
// contrary to previous ones &rarr; special tools, pas telnet
- Port UDP 53 (+ TCP in case of need){slide}
// “need” when messages are big (512 bytes, cf wikipedia)
- type = A{col1 slide}
- name: host name
- value: IP address
- type = MX{col2 mx}
- name: email domain name
- value: name of the mail server
- type = NS{col1 slide}
- name: domain name <br/>(e.g., wikipedia.org)
- value: name of the authoritative server for this domain
- type = CNAME{col2 cname}
- name: name alias
- value: canonical name
- @anim: .mx | .cname

## Adding DNS Records: say hi to the world {libyli}
- Example
- creation of the (big) SuperProject project
- wants to have a domain name <tt>superprojet.fr</tt>
// libre en 2014, plus en 2015, still taken in 2016 (no website though)
- Buying the domain name to a domain name registrar
- example of registrar: gandi.net, ovh.com{slide}
- creation of two DNS records {slide}
- <tt>(superprojet.fr, ns1.superprojet.fr, NS)</tt>
- <tt>(ns1.superprojet.fr, 222.222.222.1 , A)</tt>
- On our DNS server (ns1.superprojet.fr, IP 222.222.222.1)
// this is us, and then
- creation of other DNS records
- <tt>(www.superprojet.fr, 222.222.222.33, A)</tt>
- <tt>(superprojet.fr, mail.superprojet.fr, MX)</tt>
- …
- We can also put everything on the registrar server <br/> (and not have our DNS server)

## Attack on DNS Infrastructure
- DDoS, Distributed denial of service {slide}
- flooding root servers
- traffic filtering
- caching in local DNS
- &rArr; failure up to now
- flooding TLD servers{slide}
- more chances of success
- Man-in-the-middle: interception of requests{slide}
// sending counterfeit records
- DNS cache poisoning, DNS spoofing {slide}
- sending fake records to servers
- caching of fake records in the (clean) servers
- Using DNS servers for DDoS{slide}
- using DNS servers
- to create DDoS
// amplification: the server sends requests that are bigger than the request





<!-- P2P -->
# @copy:#plan: %+class:inred: .it6

# Peer-to-Peer (P2P) and the BitTorrent Example // who used torrents? {no-print}

## P2P Architectures
@SVG: media/part2/internet-client-server-p2p.svg 300px 400px {svg floatright}

- Pure P2P{pur}
- No server (that need to be always on)
- Any host
- peer to peer communications
- connection, disconnection // to the network
- changing IP
- In practice{pratique}
- sometimes, some support/organization servers
- or some peers that are more important
- @anim: -#arrowsclientserver + -#mask-border2 + .pur | .svg | .pratique


## How long does it take to distribute the file to all clients using a client/server architecture?{question bottom}
@SVG: media/part2/p2p-clientserver-capacities.svg 700px 150px {svg centered}

## {no-print}

## How long does it take to distribute the file to all clients using a peer-to-peer architecture?{question bottom}
@SVG: media/part2/p2p-clientserver-capacities.svg 700px 150px {svg centered}

## {no-print}



</section>


<p class="deck-status" data-progress-size=": spe.top(10, 585) ; bottom: slide.top" style="z-index: 0; color: #339; background: #EEE;"> <span class="deck-status-current"></span> / <span class="deck-status-total"></span><span class="var-author">will be replaced by the author</span><span class="var-title">will be replaced by the title</span></p>

<a data-progress-size=": spe.top(15, 555); height: 45*designRatio; left: slide.right - 70*designRatio; width: 70*designRatio" class="ccby" href="http://en.wikipedia.org/wiki/Creative_Commons_license" title="This work is under CC-BY licence." target="_blank"></a>

<a class="ujm" data-progress-size=": spe.top(15, 525); height: 65*designRatio; left: slide.left; width: 130*designRatio" target="_blank"></a> <!-- shown only if with-ujm is set on the container -->

</div>
<!-- clicky Cla -->
<script type="text/javascript">
var clicky_site_ids = clicky_site_ids || [];
clicky_site_ids.push(100779706);
(function() {
var s = document.createElement('script');
s.type = 'text/javascript';
s.async = true;
s.src = '//static.getclicky.com/js';
( document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0] ).appendChild( s );
})();
</script>
<noscript><p><img alt="Clicky" width="1" height="1" src="//in.getclicky.com/100779706ns.gif" /></p></noscript>


<!-- Histats.com START (aync)-->
<script type="text/javascript">var _Hasync= _Hasync|| [];
_Hasync.push(['Histats.start', '1,2767123,4,0,0,0,00010000']);
_Hasync.push(['Histats.fasi', '1']);
_Hasync.push(['Histats.track_hits', '']);
(function() {
var hs = document.createElement('script'); hs.type = 'text/javascript'; hs.async = true;
hs.src = ('http://s10.histats.com/js15_as.js');
(document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(hs);
})();</script>
<noscript><a href="http://www.histats.com" target="_blank"><img src="http://sstatic1.histats.com/0.gif?2767123&101" alt="javascript hit counter" border="0"></a></noscript>
<!-- Histats.com END -->
</body>
</html>