## Web Technology ### URI - Uniform Resource Identifier - Goals: - Unique identification of resources - e.g., documents, mails, websites, inboxes - Uniform schema for referencing - Extendible format - Human-readable format - Machine-readable format - Contemporary view: Everything is a URI with different schema - Format: - ` "://" [ [ ":" ] "@" ] [ ":" ] [ "/" ]` - e.g., `http://john@bitbucket.de:9000/home` --- ### HTTP - Development Goals of HTTP 0.9 - Easy Request-Response-based communication - Unique identification of resources (each HTTP request contains an URI) - Stateless protocol - Metadata for communication (headers, status codes) - Further developments - HTTP is standardized by the W3C and the IETF - Most prominent version is HTTP 1.1 - Newest version is HTTP/2 - Versions - 1991: HTTP 0.9 - 1991-1995: HTTP 1.0 - 1995-2014: HTTP 1.1 - 2014: HTTP/2 - HTTP 0.9/1.0/1.1 - Text-based protocol (easy processing) - Request-Response-interaction - Client sends request - Server sends response - Protocol stack: - HTTP: Protocol of the application layer - Thus, it requires a transport protocol (usually TCP) ![](images/02-request-response.png) ![](images/02-stack.png) #### HTTP Message ##### Request - Structure: 1. Method type - e.g., `GET /robots.txt HTTP/1.0` 2. Request header - Additional information for the request - e.g., `User-Agent: Mozilla/5.0` - e.g., `Host: www.fau.de` 3. Empty line 4. Optional Payload (*body*) - Content - Described by different headers (e.g., `Content-Type`, MIME-Type) - Methods: - `GET`: Simple data request (identified by an URI) - `POST`: Send data - State-changing operation - Data stored on the *body* - `HEAD`: Like GET, only send response header - e.g., error detection - `PUT`: Save data (create resource if it not exists) - `DELETE`: Delete a resource - `OPTIONS`: Request information about server (e.g., supported methods) ![](images/02-request.png) ##### Response - Structure 1. State - e.g., ´HTTP/1.0 200 OK` 2. Response header - e.g., `Set-Cookie: foo=bar` - e.g., `Server: Apache/2.0` 3. Empty line 4. Optional body - Data - May be arbitrary (given by Content-Type-Header) - e.g., `Content-Type: text/html` - Multiple parts: `multipart/mixed` - Status Code - 1xx: Informational response - `102 Processing` - 2xx: Success - `200 OK` - 3xx: Redirection (regard `Location` header) - `301 Moved Permanently` - 4xx: Client errors - `400 Bad request` - `404 Not found` - 5xx: Server errors - `500 Internal Server Error` - `501 Not Implemented` ![](images/02-response.png) #### TCP/IP Connections - HTTP 0.9/1.0: - One TCP/IP connection per request-response-pair - Servers are completely stateless - Problem: Repeating establishment of a new connection is expensive - TCP three-way-handshake - TCP slow-start (start transmission with few packets) - Requires system resources (network, etc.) - Enhancements: - Re-usable connection (HTTP 1.0) - Multiple requests use the same connection - `Connection: Keep-Alive` header - Default in HTTP 1.1 - *HTTP Pipelining* (HTTP 1.1) - Multiple requests after another (without waiting for the response) - Responses come in the same order - Problem: *Head-of-Line Blocking* - If one requests is blocked, all others are blocked too - Thus, use multiple TCP connections (2-8) - HTTP/2 - Binary framing layer with one TCP connection per origin - ==Where does this info come from?== #### HTTPS - **Not**: Secure-HTTP (S-HTTP) - Security concerns of HTTP: - Confidentiality: Communication is plain text - Integrity: Sent data can be manipulated - Authentication: Credentials are transferred un-encrypted - HTTP Secure: - *HTTPS*: Build HTTP on top of TCP using TLS - Default port: 443 - Scheme: `https` - Messages are *completely* encrypted - TLS is used to select encryption ciphers and keys - Workflow connection - Setup: - Browser contains a list of root CAs - Server has a certificate (indirecly) signed by one of these CAs - Browser sends supported ciphers to server - Server sends certificate (X.509) to browser - Browser checks the certificate validity and finishes the establishment of the connection ![](https://upload.wikimedia.org/wikipedia/commons/a/ae/SSL_handshake_with_two_way_authentication_with_certificates.svg) #### HTTP/2 - **Goals:** - Reduce latency (by full request-response-multiplexing) - Minimize protocol overhead (by efficient compression) - Keep semantics of HTTP 1.1 (prevent rewriting applications) - *Solve problems of HTTP 1.1* - Fix sensitivity against variable Round-Trip-Time ==What does that mean?== - Fix Head-of-line blocking - Avoid parallel TCP connections - **History:** - 2009: Start of development at Google - Research network SPDY - Goal: Reduce loading time of websites by 50 % - 2012: Chrome, Firefox and Opera support the protocol - IETF HTTP WG initiate *standardization process* - 2015: Publication of HTTP/2 and HPACK - **Overview:** - Core concept: Binary-framing layer - *Framing* is another word for *formatting* - Multiplexing: One TCP connection for the complete communication with one web server - Stream Prioritization (each request is encapsulated in a stream) - Flow control - Server push (pro-active sending of resources) - Header compression: HPACK - Three options for establishing of connections: 1. Default: Initiate connection with TLS connection over ALPN (Application-Layer Protocol Negotiation) 2. Upgrade of HTTP/1.x connection (`HTTP upgrade`) 3. Pro-active creation of HTTP/2 connection using pre-shared knowledge (e.g., DNS entry) ![](images/02-http2.png) ##### Binary Framing Layer - Task: Transmission of HTTP messages between client and server - *Layer*: - New encoding mechanism between socket and higher HTTP API - Transparent to application (only change browser and web server) - Split HTTP messages into *frames* - *Frame*: Small binary parts - Advantage: Performant, robust, correct implementation - Disadvantage: Human-readability gets lost - Binary Framing Layer concepts: - Request-Response-Multiplexing ![](https://hpbn.co/assets/diagrams/ae09920e853bee0b21be83f8e770ba01.svg) ###### HTTP/2 Connection - *Communication*: Performed over a single TCP connection carrying any number of *streams* - *Stream*: - Bi-directional communication for one or more *messages* - Has unique ID - *Message*: Complete sequence of *frames* composing a HTTP request or response - *Frame*: - Smallest logical unit for data transmission - Contains a reference to the stream in the frame header - e.g., HTTP headers, payload, ... - Frames may interleave each other - Advantage: - Improved performance (fewer TLS handshakes, less client/server resources) - Disadvantage: - Single TCP connection may suffer of TCP congestion window size reduction which reduces the maximum throughput - Result: - Experimental evidence shows, that HTTP prioritization and compress out-weight the negative effects of TCP head-of-line blocking ![](https://hpbn.co/assets/diagrams/8e6931bb40fc26c511ad15645e7b6113.svg) ###### Multiplexing - HTTP/1.x: - Parallel requests require multiple connections - So-called *Response queuing* results in *head-of-line blocking* - HTTP/2: - Parallel requests over **one** connection - Split HTTP messages, interleave them, reassemble them - Advantage: No blocking of messages -- if one message is blocked the others can be sent - HTTP/1.x optimizations are obsolete - e.g., image sprites: Single image file with multiple images - e.g., concatenating files: one big CSS file ![](https://hpbn.co/assets/diagrams/47ba5b32e42cf5a06c3741d29ef9b94a.svg) ###### Stream Prioritization - Goal: - Organize/order sent data in a way that the website can be rendered *as fast as* possible - Worst case: For all responses the headers are sent first, etc. - *Stream ‌Prioritization*: - Browser may give hints which content is required at which time - These hints may change dynamically - e.g., HTML is required first, then CSS, then images - e.g., take mouse movements into account - Weights and dependencies are a *preference* - **Technical realization:** - Each *Stream* gets a weight/priority (1 to 256) - The higher the weight, the more resources for this stream should be allocated - Each stream may have an dependency on another stream - Browser can send a *prioritization tree* for the responses - Server *can* use this information - No dependency means depend on root - These dependency trees are traversed - *Note: The arrow should be flipped for better understanding of the dependsOn-relationship* ![](https://hpbn.co/assets/diagrams/fa9ac7cba0327c032c5e1b57325496a4.svg) ###### Flow Control - *‌Flow Control*: - Mechanism to prevent that the sender overwhelms the receiver with undesired data - e.g., Client wants to pause that the servers sends of data in a single stream - Comparable to TCP flow control - TCP flow control: - Is too coarse - Limits complete connection, but HTTP/2 has multiple streams over a single connection - Technical realization: - Flow control can't be disabled - Client and server exchange a `SETTINGS` frame, which contains the *flow control window size* for both directions (default `$ 65535 $` Byte) - The window is reduced if the sender emits a `DATA` frame - The window can be increased using a `WINDOW_UPDATE` frame - *Implementation* must be done by client and server - e.g., the time of reducing the window - HTTP/2 only delivers building blocks ###### Server Push - Use case: - Client requests HTML page including CSS files - Server directly sends CSS files to prevent the client of requesting each file individually - *One request -- multiple responses* - Goal: Make information available before the browser requests them - HTTP/1.x *Inlining* is obsolete - e.g., put style sheet directly into HTML page - Difference to *inlining*: Each resource may be multiplexed/cached/declined/reused - Advantage: Reduce latency by reducing messages - Technical realization - Server sends a `PUSH_PROMISE` frame to indicate that a push will follow - Server sends `PUSH_PROMISE` before the actual `DATA` frame to inform the client (**very important**) - Server initiates new stream for the push - Browser may decline `PUSH_PROMISE` frame via `RST_STREAM` - Browser keeps pushed data in *quarantine* until he uses it ![](https://hpbn.co/assets/diagrams/d759887277b266a42c526643285dd244.svg) ##### Header Compression - Problem: - HTTP headers make up to 500-800 Byte per message - For small responses, headers are overhead - Idea: Compress headers - Using HPACK compression format - Do not re-send common headres - Technical realization: - Techniques: 1. Header fields are Huffman encoded (e.g., string compression method based on the entropy) 2. Shared index/cache/context: Sent headers are not sent again (client and server must maintain this index) - HPACK compression context: - Consists of static and dynamic tables - Static table: - Common HTTP header values - Defined by the specification - e.g. `:method: GET` - Dynamic table: - Contains headers which are not defined in the specification and is build over the connection lifecycle - Initially empty - One per (TCP-)connection ![](https://hpbn.co/assets/diagrams/feb142f82737d148ed5bcefd91915276.svg). --- ### HTML and CSS - Browser visualizes documents written in HTML - *Markup language*: - Machine-readable language for structure and rendering - e.g., `WBS lecture` - HTML: - HyperText Markup language - Default rendering defined by browser - The *What* - CSS: - Define rendering - The *How* - History: - Past: HTML was static - Current: HTML documents are dynamically generated on the server side and modified by the browser #### HTML - *HyperText Markup Language*: - Text-based markup language for the structuring and rendering of digital documents such as texts with hyperlinks - Versions: - 1991: HTML 1 - 1995: HTML 2 - 1997: HTML 3 - 1997: HTML 4 - 2000: XHTML - Based on HTML 4.01 XHTML 1.0 was created - XHTML is HTML conform with XML and therefore stricter (not used) - 2014: HTML5 - Charset: - Usually, UTF-8 or ISO-8859-1 (Latin-1) - e.g., `` - Special characters: - So-called *character entities* - Format: `&;` - e.g., `&` for `&` #### HTML Tags - Purpose: - Formatting information (e.g., italic `i`) - Structure information - e.g., headings, paragraph, lists, images - Formatting information are ignored (e.g., whitespaces, tabs, newlines, etc.) - Types: - Block tags - Define a rectangular area - e.g., `div`, `p` - Inline tags (e.g., `i`) ##### Structure - Tags are contained inside `<.>` - Most tags have an end-tag (i.e., container) - XHTML: - Single tags must be closed `
` - Case-sensitive (all lowercase) - HTML5: - Single tags can be open `
` - Case-insensitive ##### Attributes - Key-value pair providing additional information - Order does not matter - Quotation marks: - XHTML: Required - HTML5: Not required -- implicitly given by a space - *Graceful degradation*: - Property of a system (here: browser) to reduce errors - New/unknown attributes are usually ignored by the browser - e.g., if a browser does not load the `img` tag, it shows the alternative text - e.g., if a browser does not know the `type=email`, it renders the input field as text field - e.g., `Title` ##### Tags for Text - Block tags: - e.g., `p`, `h1`-`h6`, `nav`, `header`, `footer`, `blockquote` - Inline tags: - Must be used *within* a block tag - e.g., `em`, `strong`, `b`, `span` - Difference *logical* and *physical* elements: - e.g., difference between `b` and `strong` - `b` is *physical*: Render boldface - `strong` is *logical*: Text is emphasized (but not necessarily boldface) - Physical tags are considered *deprecated* ##### Other Tags - Images: - `img` - Reference using absolute/relative reference - Supported formats: SVG, GIF, JPG, PNG - Links: - e.g., `Caption` - Lists: - Unordered list: `ul`‌ - Ordered list: `ol` - List item: `li` - Tables: - Table: `table` - Table row: `tr` - Table data: `td` - Historically, tables were used for the layout (deprecated) ![](images/03-html.png) #### CSS - Motivation: - Separate *content* and *representation* - e.g., prevent `...` - Goal: More flexibility by using classes and IDs - Advantages: - Uniform rendering of different websites in different browsers (e.g., corporate identity) - Style definitions are centralized - Additional design features - Split work (designer and writer) - Style sheet consists of several rules ##### Rule Structure - Rule consists of a selector and several declarations - Components: - Selector - Declaration Block - Property - Value ![](images/04-rule.png) ##### Reference in HTML - `link` tag (external source) - `style` tag (local definition) - `style` attribute (for specific tags) - Order of importance: 1. Attribute (of a tag) 2. Local definition 3. External source ##### Selectors - Tag name/type - Classes - Tag may contain several classes - cf. format template - e.g., `class="class"` - e.g., `.class {...}` - IDs - Tag may have at most one ID (unique) - e.g., `id="test"` - e.g., `#test {...}` - Wildcard `*` - *Group selector*: - Combination of multiple selectors - e.g., `h1, h2, a` - *Descendant selector*: - Select children/descendants - e.g., `p.text > span.red:hover` - *Pseudo-selectors*: - e.g., `:link`, `:visited`, `:first-child` - Interaction: `:hover`, `:active` - Tags for styling without properties: - `div`: Block tag - `span`: Inline tag (continuous text) ##### Variables - So-called *custom properties* - Define: `--foo: ` - Access: `var(--foo)` - e.g., `:root { --foo: #fff; }` ![](images/04-vars.png) ##### Properties - Size (width, height, margin) - Font (size, family, weight) - Font family either needs to be installed in the browser or via dynamically loaded Webfonts - Color - Predefined names (e.g., red, green) - RGBA (e.g., `rgba(15,0,255,0.9)`) - Hex (e.g., `#1000FF`) - Background color - Position - Visibility (block, none) ##### Measures - Relative: - `em`: Width of letter *m* - `rem`: Font size of html element - `vw`: View width (in percent) - Absolute: - Pixel `px` - Millimeter `mm` - Centimeter `cm` - Inch `in` - Colors: `color`, `background-color` ##### Box Model - Components of a *block*: - Margin - Border (Background-image goes up to the border) - Padding - Content - Use the `box-sizing` property - `content-box`: Default, `width` applies to the content (not to padding, border and margin) - `border-box`: `width` applies to the border (content + padding + border) ![](images/04-box.png)