2.a) Easier for clients to send data to the server.

b) Client does not have a fixed port number unlike server because client need to
contact the server first before it can receive the data from the server. Only t
hen server can have client port number to send the data to the client.
5. AUTHORITATIVE SERVER
a master/slave server for a particular domain that has been configured by an adm
inistrator with the hostname information for that domain. Information about thes
e servers is added to the root servers when the domain is registered.
LOCAL
a local name server that only caches information for local clients once it has b
een retrieved from an authoritative name server. The local server can effectivel
y speed up name queries for the local network by serving up names found by prior
queries, preventing a request to the authoritative server for that host's domai
n.
6 a)
b) 1. The server disconnects before the the request has been sent
2. The request is sent, but no response is received because the server has disco
nnected
c)Request and Response Multiplexing
The ability to break down an HTTP message into independent frames, interleave th
em, and then reassemble them on the other end is the single most important enhan
cement of HTTP/2. In fact, it introduces a ripple effect of numerous performance
benefits across the entire stack of all web technologies, enabling us to:
-Interleave multiple requests in parallel without blocking on any one
-Interleave multiple responses in parallel without blocking on any one
-Use a single connection to deliver multiple requests and responses in parallel
-Remove unnecessary HTTP/1.x workarounds (see Optimizing for HTTP/1.x ), such as co
ncatenated files, image sprites, and domain sharding
-Deliver lower page load times by eliminating unnecessary latency and improving
utilization of available network capacity
The new binary framing layer in HTTP/2 resolves the head-of-line blocking proble
m found in HTTP/1.x and eliminates the need for multiple connections to enable p
arallel processing and delivery of requests and responses. As a result, this mak
es our applications faster, simpler, and cheaper to deploy.
STREAM PRIORITIZATION
the HTTP/2 standard allows each stream to have an associated weight and dependen
cy:
-Each stream may be assigned an integer weight between 1 and 256
-Each stream may be given an explicit dependency on another stream
The combination of stream dependencies and weights allows the client to construc

t and communicate a "prioritization tree" that expresses how it would prefer to

receive the responses. In turn, the server can use this information to prioritiz
e stream processing by controlling the allocation of CPU, memory, and other reso
urces, and once the response data is available, allocation of bandwidth to ensur
e optimal delivery of high-priority responses to the client.
Server Push
new feature of HTTP/2 is the ability of the server to send multiple responses fo
r a single client request. That is, in addition to the response to the original
request, the server can push additional resources to the client without the clie
nt having to request each one explicitly!
Header Compression
HTTP/2 compresses request and response header metadata using the HPACK compressi
on format that uses two simple but powerful techniques:
It allows the transmitted header fields to be encoded via a static Huffman code,
which reduces their individual transfer size.
It requires that both the client and server maintain and update an indexed list
of previously seen header fields (i.e. establishes a shared compression context)
, which is then used as a reference to efficiently encode previously transmitted
values.
Huffman coding allows the individual values to be compressed when transferred, a
nd the indexed list of previously transferred values allows us to encode duplica
te values (Figure 12-6) by transferring index values that can be used to efficie
ntly look up and reconstruct the full header keys and values.
BINARY FRAMING
At the core of all HTTP/2 improvements is the new binary, length-prefixed framin
g layer.
Once an HTTP/2 connection is established, the client and server communicate by e
xchanging frames, which serve as the smallest unit of communication within the p
rotocol. All frames share a common 9-byte header which contains the length of th
e frame, its type, a bit field for flags, and a 31-bit stream identifier.
Technically, the length field allows payloads of up to 224 bytes (~16MB) per fra
me. However, the HTTP/2 standard sets the default maximum payload size of DATA f
rames to 214 bytes (~16KB) per frame and allows the client and server to negotia
te the higher value. Bigger is not always better: smaller frame size enables eff
icient multiplexing and minimizes head-of-line blocking.
8 a) 01000001 & 01000010
b)