Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Angelo van der Sijpt - How well do you know your network stack? - Codemotion Amsterdam 2019

14 visualizaciones

Publicado el

Networking is a core part of computing in the digital world we inhabit. But, how well do you know how it works? Do you understand all the moving parts of the OSI stack inside your computer, and how the network is actually put together? How can this ever work? This guided safari of layers, standards, protocols, and happenstance will bring us close to the copper wire, and up through the layers of CDMA/CD, ARP, routing and HTTP. We will make a few excursions through patchworks that still work forty years later, and cleverly designed mechanisms that show that simplicity is the only way to last.

Publicado en: Tecnología
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Angelo van der Sijpt - How well do you know your network stack? - Codemotion Amsterdam 2019

  1. 1. How well do you know your network stack? Angelo van der Sijpt Amsterdam | April 2-3, 2019
  2. 2. Angelo van der Sijpt Fellow @ Luminis Eindhoven Running, OCR, Krav Maga @_angelos
 angelo.vandersijpt@luminis.eu
  3. 3. https://www.iso.org/standard/20269.html
  4. 4. Network Working Group Steve Crocker Request for Comments: 1 UCLA 7 April 1969 Title: Host Software Author: Steve Crocker Installation: UCLA Date: 7 April 1969 Network Working Group Request for Comment: 1 CONTENTS INTRODUCTION I. A Summary of the IMP Software Messages Links IMP Transmission and Error Checking Open Questions on the IMP Software II. Some Requirements Upon the Host-to-Host Software Simple Use Deep Use Error Checking III. The Host Software Establishment of a Connection High Volume Transmission A Summary of Primitives Error Checking Closer Interaction Open Questions Crocker [Page 1] Network Working Group Request for Comments: 1 Title: Host Software Author: Steve Crocker Installation: UCLA Date: 7 April 1969 Network Working Group Request for Com CONTENTS INTRODUCTION I. A Summary of the IMP Software Messages Links IMP Transmission and Error Checking Open Questions on the IMP Software II. Some Requirements Upon the Host-to-Host Softw Simple Use Deep Use Error Checking https://tools.ietf.org/rfc/index
  5. 5. 1 Cabling
  6. 6. https://en.wikipedia.org/wiki/Modular_connector https://en.wikipedia.org/wiki/Twisted_pair https://en.wikipedia.org/wiki/Category_6_cable
  7. 7. Class Channel Category A 100 kHz 1 B 1 MHz 2 C 16 MHz 3 D 100 MHz 5e E 250 MHz 6 EA 500 MHz 6A F 600 MHz 7 FA 1000 MHz 7A
  8. 8. 2 Wireprotocols
  9. 9. 802.3ab 1000BASE-T “Gigabit ethernet”
  10. 10. data symbols
 PAM5 110 010 001 111 00 0101 10 voltages-2 1 2 0 pairs
  11. 11. 2 Ethernet
  12. 12. destination source type
  13. 13. destination source type MAC address
  14. 14. destination source type
  15. 15. destination source type
  16. 16. destination source type
  17. 17. destination source type EtherType Protocol 0x0800 IPv4 0x0806 ARP 0x8137 IPX 0x86DD IPv6
  18. 18. destination source typepreamble payload crc gap preamble crc gap 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101011 4 byte checksum EOD symbol +
 12 bytes silence
  19. 19. 3 IP
  20. 20. RFC: 791 INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION September 1981 prepared for Defense Advanced Research Projects Agency Information Processing Techniques Office 1400 Wilson Boulevard Arlington, Virginia 22209 by Information Sciences Institute University of Southern California 4676 Admiralty Way Marina del Rey, California 90291 INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION September 1981 prepared for Defense Advanced Research Projects Agency Information Processing Techniques Office 1400 Wilson Boulevard Arlington, Virginia 22209
  21. 21. version IHL version DSCP ECN Length Ident Flags Fragoffs TTL Protocol Checksum source destination
  22. 22. TTL Protocol source destination Number Protocol 1 ICMP 6 TCP 115 L2TP 4 IPv4 encapsulation
  23. 23. TTL Protocol source destination 11000000 192 10101000 168 00000010 2 10010110 150 ip address 11111111 11111111 11111111 00000000 netmask 192.168.2.0/24 CIDR network nr 11000000 192 10101000 168 00000010 2 host nr 10010110 150
  24. 24. .3 .150 .1 192.168.2.0/24 .5 10.0.1.0/24 192.168.2.150 192.168.2.3
  25. 25. .3 .150 .1 192.168.2.0/24 .5 10.0.1.0/24 192.168.2.150 192.168.2.3 0c:4d:e9:b9:7b:14 9c:93:4e:6c:6d:65
  26. 26. .3 .150 .1 192.168.2.0/24 .5 10.0.1.0/24 192.168.2.150 10.0.1.5
  27. 27. .3 .150 .1 192.168.2.0/24 .5 10.0.1.0/24 192.168.2.150 10.0.1.5 0c:4d:e9:b9:7b:14 80:2a:a8:4d:3b:c1
  28. 28. .3 .150 .1 192.168.2.0/24 .5 10.0.1.0/24 192.168.2.150 10.0.1.5 0c:4d:e9:b9:7b:14 80:2a:a8:4d:3b:c1
  29. 29. .3 .150 .1 192.168.2.0/24 .5 10.0.1.0/24 192.168.2.150 10.0.1.5 0c:4d:e9:b9:7b:14 80:2a:a8:4d:3b:c1
  30. 30. .3 .150 .1 192.168.2.0/24 .5 10.0.1.0/24 192.168.2.150 10.0.1.5 0c:4d:e9:b9:7b:14 f0:9f:c2:2f:7a:fb
  31. 31. TTL Protocol source destination .3 .150 .1 192.168.2.0/24 .5 10.0.1.0/24
  32. 32. TTL Protocol source destination .3 .150 .1 192.168.2.0/24 .5 10.0.1.0/24 63
  33. 33. TTL Protocol source destination .3 .150 .1 192.168.2.0/24 .5 10.0.1.0/24 62
  34. 34. 4 TCP
  35. 35. Out of order Non-guaranteed
  36. 36. 5 4 13 2 143 4 12
  37. 37. 5 4 13 2 143 4 122! ✔✔
  38. 38. 5 4 13 2 143 4 12 2! 45 3x 35✔✔
  39. 39. 5 4 13 2 143 4 12 2! 45 3x 355!✔✔✔ ✔✔
  40. 40. 7 HTTP
  41. 41. Fielding, et al Standards Track [Page 1] Network Working Group R. Fielding Request for Comments: 2616 UC Irvine Obsoletes: 2068 J. Gettys Category: Standards Track Compaq/W3C J. C. Mogul Compaq H. Frystyk W3C/MIT L. Masinter Xerox P. Leach Microsoft T. Berners-Lee W3C/MIT June, 1999 Hypertext Transfer Protocol -- HTTP/1.1 Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the “Internet Official Protocol Standards” (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as “HTTP/1.1”, and is an update to RFC 2068 [33].
  42. 42. 5.1.1 Method The Method token indicates the method to be performed on the resource identified by the Reque method is case-sensitive. Method = "OPTIONS" ; Section 9.2 | "GET" ; Section 9.3 | "HEAD" ; Section 9.4 | "POST" ; Section 9.5 | "PUT" ; Section 9.6 | "DELETE" ; Section 9.7 | "TRACE" ; Section 9.8 | "CONNECT" ; Section 9.9 | extension-method extension-method = token The list of methods allowed by a resource can be specified in an Allow header field (section 14.7) of the response always notifies the client whether a method is currently allowed on a resource, since allowed methods can change dynamically. An origin server SHOULD return the status code 405 (M Allowed) if the method is known by the origin server but not allowed for the requested resource, an Implemented) if the method is unrecognized or not implemented by the origin server. The methods MUST be supported by all general-purpose servers. All other methods are OPTIONAL; however, if methods are implemented, they MUST be implemented with the same semantics as those specified i 5.1.2 Request-URI The Request-URI is a Uniform Resource Identifier (section 3.2) and identifies the resource upon the request. Request-URI = "*" | absoluteURI | abs_path | authority The four options for Request-URI are dependent on the nature of the request. The asterisk “*” m request does not apply to a particular resource, but to the server itself, and is only allowed when the does not necessarily apply to a resource. One example would be Fielding, et al Standards Track [Pa | extension-method extension-method = token The list of methods allowed by a resource can be specified in an Allow header field (section 14.7). T of the response always notifies the client whether a method is currently allowed on a resource, since th allowed methods can change dynamically. An origin server SHOULD return the status code 405 (Met Allowed) if the method is known by the origin server but not allowed for the requested resource, and 5 Implemented) if the method is unrecognized or not implemented by the origin server. The methods GE MUST be supported by all general-purpose servers. All other methods are OPTIONAL; however, if th methods are implemented, they MUST be implemented with the same semantics as those specified in 5.1.2 Request-URI The Request-URI is a Uniform Resource Identifier (section 3.2) and identifies the resource upon w the request. Request-URI = "*" | absoluteURI | abs_path | authority The four options for Request-URI are dependent on the nature of the request. The asterisk “*” mea request does not apply to a particular resource, but to the server itself, and is only allowed when the m does not necessarily apply to a resource. One example would be Fielding, et al Standards Track [Pag quoted-pair = "" CHAR 3 Protocol Parameters 3.1 HTTP Version HTTP uses a “<major>.<minor>” numbering scheme to indicate versions of the protocol. The protocol policy is intended to allow the sender to indicate the format of a message and its capacity for understan HTTP communication, rather than the features obtained via that communication. No change is made to number for the addition of message components which do not affect communication behavior or which extensible field values. The <minor> number is incremented when the changes made to the protocol ad which do not change the general message parsing algorithm, but which may add to the message semant additional capabilities of the sender. The <major> number is incremented when the format of a messag protocol is changed. See RFC 2145 [36] for a fuller explanation. The version of an HTTP message is indicated by an HTTP-Version field in the first line of the mess HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT Note that the major and minor numbers MUST be treated as separate integers and that each MAY be in higher than a single digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower th HTTP/12.3. Leading zeros MUST be ignored by recipients and MUST NOT be sent. An application that sends a request or response message that includes HTTP-Version of “HTTP/1.1” least conditionally compliant with this specification. Applications that are at least conditionally complia specification SHOULD use an HTTP-Version of “HTTP/1.1” in their messages, and MUST do so for a | Upgrade ; Section 14.42 | Via ; Section 14.45 | Warning ; Section 14.46 header field names can be extended reliably only in combination with a change in the protocol version. , new or experimental header fields may be given the semantics of general header fields if all parties in the cation recognize them to be general-header fields. Unrecognized header fields are treated as entity-header quest message from a client to a server includes, within the first line of that message, the method to be applied to rce, the identifier of the resource, and the protocol version in use. Request = Request-Line ; Section 5.1 *(( general-header ; Section 4.5 | request-header ; Section 5.3 | entity-header ) CRLF) ; Section 7.1 CRLF [ message-body ] ; Section 4.3 equest-Line uest-Line begins with a method token, followed by the Request-URI and the protocol version, and ith CRLF. The elements are separated by SP characters. No CR or LF is allowed except in the final CRLF . Request-Line = Method SP Request-URI SP HTTP-Version CRLF ethod hod token indicates the method to be performed on the resource identified by the Request-URI. The RFC 2616 HTTP/1.1 J Recipients of an HTTP/1.0 request that lacks a Host header field MAY attempt to use heuristics of the URI path for something unique to a particular host) in order to determine what exact resour requested. 5.3 Request Header Fields The request-header fields allow the client to pass additional information about the request, and abo to the server. These fields act as request modifiers, with semantics equivalent to the parameters on language method invocation. request-header = Accept ; Section 14.1 | Accept-Charset ; Section 14.2 | Accept-Encoding ; Section 14.3 | Accept-Language ; Section 14.4 | Authorization ; Section 14.8 | Expect ; Section 14.20 | From ; Section 14.22 | Host ; Section 14.23 RFC 2616 HTTP/1.1 June, 1999 | Upgrade ; Section 14.42 | Via ; Section 14.45 | Warning ; Section 14.46 General-header field names can be extended reliably only in combination with a change in the protocol version. However, new or experimental header fields may be given the semantics of general header fields if all parties in the communication recognize them to be general-header fields. Unrecognized header fields are treated as entity-header fields. 5 Request A request message from a client to a server includes, within the first line of that message, the method to be applied to the resource, the identifier of the resource, and the protocol version in use. Request = Request-Line ; Section 5.1 *(( general-header ; Section 4.5 | request-header ; Section 5.3 | entity-header ) CRLF) ; Section 7.1 CRLF [ message-body ] ; Section 4.3
  43. 43. FC 2616 HTTP/1.1 June, 1999 he first digit of the Status-Code defines the class of response. The last two digits do not have any ategorization role. There are 5 values for the first digit: • 1xx: Informational - Request received, continuing process • 2xx: Success - The action was successfully received, understood, and accepted • 3xx: Redirection - Further action must be taken in order to complete the request • 4xx: Client Error - The request contains bad syntax or cannot be fulfilled • 5xx: Server Error - The server failed to fulfill an apparently valid request he individual values of the numeric status codes defined for HTTP/1.1, and an example set of corresponding eason-Phrase’s, are presented below. The reason phrases listed here are only recommendations -- they MAY e replaced by local equivalents without affecting the protocol. Status-Code = "100" ; Section 10.1.1: Continue | "101" ; Section 10.1.2: Switching Protocols | "200" ; Section 10.2.1: OK | "201" ; Section 10.2.2: Created Fielding, et al Standards Track [Page 26] communication recognize them to be request-header fields. Unrecognized header fields are treated as entity-header fields. 6 Response After receiving and interpreting a request message, a server responds with an HTTP response message. Response = Status-Line ; Section 6.1 *(( general-header ; Section 4.5 | response-header ; Section 6.2 | entity-header ) CRLF) ; Section 7.1 CRLF [ message-body ] ; Section 7.2 6.1 Status-Line The first line of a Response message is the Status-Line, consisting of the protocol version followed by a numeric status code and its associated textual phrase, with each element separated by SP characters. No CR or LF is allowed except in the final CRLF sequence. Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 6.1.1 Status Code and Reason Phrase The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes are fully defined in section 10. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason-Phrase.
  44. 44. 2 3 4 7 DOCSIS DNS DHCP UDP
  45. 45. Network Working Group P. Mockapetris Request for Comments: 1035 ISI November 1987 Obsoletes: RFCs 882, 883, 973 DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION 1. STATUS OF THIS MEMO This RFC describes the details of the domain system and protocol, and assumes that the reader is familiar with the concepts discussed in a companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034]. The domain system is a mixture of functions and data types which are an official protocol and functions and data types which are still experimental. Since the domain system is intentionally extensible, new data types and experimental behavior should always be expected in parts of the system beyond the official protocol. The official protocol parts include standard queries, responses and the Internet class RR data formats (e.g., host addresses). Since the previous RFC set, several definitions have changed, so some previous definitions are obsolete. Experimental or obsolete features are clearly marked in these RFCs, and such information should be used with caution. The reader is especially cautioned not to depend on the values which appear in examples to be current or complete, since their purpose is primarily pedagogical. Distribution of this memo is unlimited. Table of Contents 1. STATUS OF THIS MEMO 1 2. INTRODUCTION 3 2.1. Overview 3 2.2. Common configurations 4 2.3. Conventions 7 2.3.1. Preferred name syntax 7 2.3.2. Data Transmission Order 8 2.3.3. Character Case 9 2.3.4. Size limits 10 3. DOMAIN NAME SPACE AND RR DEFINITIONS 10 3.1. Name space definitions 10 3.2. RR definitions 11 3.2.1. Format 11 3.2.2. TYPE values 12 3.2.3. QTYPE values 12 3.2.4. CLASS values 13 Mockapetris [Page 1] 7 DNS Obsoletes: RFCs 882, 883, 973 DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION 1. STATUS OF THIS MEMO This RFC describes the details of the domain system and protoc assumes that the reader is familiar with the concepts discusse companion RFC, "Domain Names - Concepts and Facilities" [RFC-1 The domain system is a mixture of functions and data types whi official protocol and functions and data types which are still experimental. Since the domain system is intentionally extens data types and experimental behavior should always be expected of the system beyond the official protocol. The official prot include standard queries, responses and the Internet class RR formats (e.g., host addresses). Since the previous RFC set, s definitions have changed, so some previous definitions are obs Experimental or obsolete features are clearly marked in these such information should be used with caution. The reader is especially cautioned not to depend on the values appear in examples to be current or complete, since their purp
  46. 46. 7 6 5 4 3 2 1 DHCP DNS Switch Switch Gateway Ziggo … Loadbalancer Webserver Switch Applicationserver
  47. 47. 7 6 5 4 3 2 1 1 11801568 802.3ab RFC: 791 INTERNET PROTOCOL DARPA INTERNET PROGRAM RFC: 791 INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION September 1981 Network Working Group Request For Comments: 826 An Ethernet Address Resoluti -- or -- Converting Network Protocol to 48.bit Ethernet Add Network Working Group Request For Comments: 826 An Ethernet Address Resolution Protocol -- or -- Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware RFC: 793 TRANSMISSION CONTROL PROTOCOL DARPA INTERNET PROGRAM RFC: 793 TRANSMISSION CONTROL PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION September 1981 Network Working Group R. Fielding Request for Comments: 2616 UC Irvine Obsoletes: 2068 J. Gettys Category: Standards Track Compaq/W3C J. C. Mogul Compaq H. Frystyk W3C/MIT L. Masinter Xerox P. Leach Microsoft T. Berners-Lee W3C/MIT June, 1999 Hypertext Transfer Protocol -- HTTP/1.1 Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the “Internet Official Protocol Standards” (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as “HTTP/1.1”, and is an update to RFC 2068 [33]. Fielding, et al Standards Track [Page 1] P. Leach Microsoft T. Berners-Lee W3C/MIT June, 1999 Hypertext Transfer Protocol -- HTTP/1.1 Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the “Internet Official Protocol Standards” (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as “HTTP/1.1”, and is an update to RFC 2068 [33].
  48. 48. 7 6 5 4 3 2 1 1 11801568 802.3ab RFC: 791 INTERNET PROTOCOL DARPA INTERNET PROGRAM RFC: 791 INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION September 1981 Network Working Group Request For Comments: 826 An Ethernet Address Resoluti -- or -- Converting Network Protocol to 48.bit Ethernet Add Network Working Group Request For Comments: 826 An Ethernet Address Resolution Protocol -- or -- Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware RFC: 793 TRANSMISSION CONTROL PROTOCOL DARPA INTERNET PROGRAM RFC: 793 TRANSMISSION CONTROL PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION September 1981 Network Working Group R. Fielding Request for Comments: 2616 UC Irvine Obsoletes: 2068 J. Gettys Category: Standards Track Compaq/W3C J. C. Mogul Compaq H. Frystyk W3C/MIT L. Masinter Xerox P. Leach Microsoft T. Berners-Lee W3C/MIT June, 1999 Hypertext Transfer Protocol -- HTTP/1.1 Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the “Internet Official Protocol Standards” (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as “HTTP/1.1”, and is an update to RFC 2068 [33]. Fielding, et al Standards Track [Page 1] P. Leach Microsoft T. Berners-Lee W3C/MIT June, 1999 Hypertext Transfer Protocol -- HTTP/1.1 Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the “Internet Official Protocol Standards” (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as “HTTP/1.1”, and is an update to RFC 2068 [33]. IPX/SPXXNS DECnet
  49. 49. Angelo van der Sijpt @_angelos 1 2 3 4 5 6 7 Cabling Wire protocols Ethernet IP ARP 2,5 TCP HTTPDOCSIS DNS DHCP UDP Connectors, voltages, Hz Encoding, using pairs MAC, relay, hub vs switch IP over Ethernet, subnets, routing, TTL, NAT Address resolution exchange Reliable messaging, sliding window, ports Methods, status codes

×