Skip navigation
All Places > Web Performance > Blog
1 2 3 Previous Next

Web Performance

242 posts

Valued Customer,

 

This week, Web Performance is publishing a set of new Reports with an improved user experience.

 

What’s Happening:

 

  1. A new link, “Reporting (Beta),” is appearing in the “Monitor” menu.
  2. A set of Web Performance reports based on your Akamai Services will be available in this new experience.  The list of reports will grow as more reports are published.
  3. Older versions of published reports will remain visible for approximately 90 days after the new reports are published, and then will be removed from the "Monitor" menu.
  4. Existing active Recurring reports will be re-scheduled before old reports are removed.
  5. Feedback surveys will be made available within the new reports, to collect your feedback and let Akamai know what you want to see next.
  6. Highlights of the new experience include:

 

What’s Changing:

Why it Matters:

New consolidated "Reporting (Beta)" menu link under "Monitor" and available report list with auto-complete functionality.

Easier to find Reports of interest.

Updated UI & visualizations.

Updated look with improved User interactions.

Users can multi select and multi deselect CP Codes / traffic segments with auto-complete functionality.

Easier to find data of interest, removing reliance on A-Z and 0-9 sorting.

User's previous filter selections for a report are remembered and applied each time they view it.

Users can pick up where they left off.

Some reports will support extended data retention and be able to present data for > 90 days, as data is accrued.

Users will be able to see greater amounts of historical data for select reports.

 

 

 

 

Date/time selections are paired with more data granularities and time zone selections.

Users have more control over the window of date/time they wish to examine.


Users can change the timezone within the report, without having to go back to their Profile.


Users will be presented 5 minute data granularity for 1 day ranges with all timezones, 1 hour data granularity for 1 week ranges with all 1 hour timezones, and 1 day data granularity for 1 month/year ranges with UTC 00:00 (GMT).

Filters and DateTime selections apply to all data visualizations in a Report.

Consistent User experience within reports.

 


Updates to scheduling flexibility and output format.

Users can configure custom “Weekly” and “Monthly” schedules, can edit existing schedule parameters and do not have to schedule multiple parts of the same report.  

 

"Image" and CSV outputs are available.  

Reporting OPEN API will be available for reports.

Enables more ways to interact with Akamai data

Help contains information on how to use Filters, Date/Time selections, and new features, along with concise explanations of each report’s content.

 

Easier to read and find information within Help.

UI Users will be prompted to schedule reports with large data sets for delivery via e-mail.

Improve success rates for larger data sets.

 

 

 

Thank You,

 

The Web Performance and Reporting Teams

Last month we made available functionality to enable all users to go faster on web delivery products. Activation times are now down to ~10 mins for all delivery products. In time for Edge, we want to enable users to go even faster! Today we are releasing more activation functionality to enable users to start validating their changes early and revert back changes via fast fallback.

 

The gory details:

 

Early Validation

To ensure complete safety, Akamai goes through a phased deployment process and runs a series of safety checks when a property is activated. Changes are first implemented on servers actively serving the user’s traffic, then to the rest of the global Akamai network, and then we run our safety checks to completely bless the activation. If we detect any problems, we will automatically cancel the activation and send a notification.

 

However we want to encourage users to go EVEN faster by displaying these intermediate milestone within our process.

 

Our enhanced tracking bar (pictured below) shows each stage of the process. This provides you the benefit of monitoring our background tasks while going about your workflows based on your preferences.

 

 

 

 

We expose the three milestones above via UI notifications or API endpoints :

  • Stage 1 (Live): Deploying the property version to the Akamai edge servers currently serving user traffic. After this stage is complete, users can begin validating your changes in instances where they expect no change in their traffic patterns -  this is especially powerful in dev&test environments.
  • Stage 2 (Fully Deployed):  Completing deployment to Akamai’s network. After this stage, updates are now on the entire global Akamai network and users can confidently test and validate changes irrespective of traffic patterns
  • Stage 3 (Completed):  Performing safety checks on this property version to ensure updates are successful before completing the activation. If we detect a problem, the property automatically rolls back to the last active version in minutes

 

 

Fast Fallback

 

An equally important DevOps need today is to  continuously test and validate multiple changes in your environment quickly. After an activation is complete, there will be a one-hour window to revert (fall back) the configuration to your last (most recent) active property version in ~1 minute on staging and ~4  mins on production.

 

As an example, let’s say you just went live with version 4 of your property’s configuration on Akamai’s network, and then activated version 5 with some caching updates. Within a few minutes of version 5 going active on Akamai’s network, you notice something looks off -  the last change in your environment was this Akamai configuration update. Fast Fallback lets you quickly revert to your last active property configuration much faster than a regular activation and continue iterating.

 

Fast Fallback is available both via the UI and API

 

Note: If you miss the one-hour window, and want to revert to a previously active version, return to the Property Details page, select the active version to which you want to revert, and activate it. Also at least one complete activation needs to occur between successive Fast Fallback executions

 

 

 

Exceptions for Fast Activation and Fast Fallback:

Activations/Fallbacks will take about 45 mins for these scenarios:

  • New properties (This applies to first time activations.)
  • Property versions where a hostname was added or removed (The new version has different hostname information than the property version that is currently active on the network) 

 

Note: The current UI still shows approximate times for the older activation path. We are currently working on fixing this.

Last month (September 2017) the IETF Ratified RFC 8246 HTTP Immutable Responses, a new mechanism to inform clients that content will not be updated during it's freshness lifetime.

 

Immutable responses were first introduced in Firefox 49 and were quickly picked up by Facebook where this particular approach is well suited to social media contexts where constant reloading of content is common.

 

So what does Cache Immutable do?

To quote from the RFC document itself:

The immutable HTTP response Cache-Control extension allows servers to identify resources that will not be updated during their freshness lifetime. This ensures that a client never needs to re-validate a cached fresh resource to be certain it has not been modified.

In simpler terms, tell the browser that the response to the current request won't change during the time the Cache-Control TTL (max-age) is valid in the browser cache. It does this by appending the "immutable" flag to the end of the downstream Cache-Control header:

 

Cache-Control: max-age=31536000, immutable

 

The benefit of this is thus - if the content is immutable and you reload/refresh the page, if the browser has the content in it's cache and it's TTL hasn't expired, then it should use it regardless without even bothering to try and re-validate it with the source server. This obviously saves a round-trip to the server where even doing an If-Modified-Since check still takes some time.

 

Which browsers support the immutable flag?

At time of writing:

 

What sort of content can be marked immutable?

This is mostly down to the content provider to decide but the most obvious candidates are:

  • Long tail content with big TTL values.
  • Content with versioning information in URLs.
  • URLs that use unique ID's or hashes that are never re-used or updated in-place.

 

So for example, if you're CMS publishes CSS files with a version parameter such as http://www.example.com/main.css?v=12345 or uses a unique filename for each image such as http://images.example.com/CD45DE3F2F6A0031.jpg, these would be good candidates.

 

Implementing the Immutable flag with Property Manager

If you don't wish or are unable to implement the flag at your origin, you can add the immutable flag at the point of delivery from the Akamai edge using Property Manager.

 

Currently the simplest way to do this is to use an Advanced behaviour which requires some assistance from Akamai Professional Services for the initial implementation. However it's fairly simple and doesn't take to long and could be converted to a Custom Behaviour later on fairly simply.

 

It has been suggested that we add the option to add this flag to the default default Downstream Caching behaviour so it may appear as a simple check-box option in the future.

 

Lets say you already have a Caching rule in your configuration to cache CSS and JS resources with a Akamai cache TTL of 1 day. Your immutable resources use versioning by means of a ?v= query string in the resource URL.

 

To add the immutable flag, you could implement a Property Manager rule as follows:

 

  • Create a new blank rule, name it and set matches on cacheable responses and the necessary criteria to ensure immutable content is identified.
  • Use a Downstream Caching behaviour to set the default Cache-Control behaviour and to ensure one is always added at the edge.
  • Use the Advanced behaviour to append the immutable flag to the end of the header at the point we deliver it to the client.

 

The first two points are important. Make sure you only flag content you truly want immutable as by design, the browser will not re-validate it for the duration on the TTL. Likewise the actual downstream TTL (max-age) value should be carefully selected. Re-validation won't occur until this has expired so either use the remaining Akamai edge TTL or a fixed value - you know best what works for you.

 

A cache immutable rule

 

In the above example, we check the cacheablity status and that the query string parameter "v" exists which indicates that the URLs use versioning to identify unique content. The default Downstream Cacheablity behaviour ensures we send a Cache-Control header and in this example sets max age to the TTL remaining of the object in the Akamai Edge cache.

 

The Advanced behaviour snippet is as follows and simple appends the immutable flag to the end of the Cache-Control header. Because the Modifying Outgoing Response behaviour in Property Manager doesn't support capture groups, we need to use this method for now.

<match:request.type value="CLIENT_REQ">
    <match:metadata-stage value="client-response">
        <edgeservices:modify-outgoing-response.regexp-header>
            <status>on</status>
            <name>Cache-Control</name>
            <value>#(.*)#$1, immutable#ig</value>
            <edge-only>on</edge-only>
        </edgeservices:modify-outgoing-response.regexp-header>
    </match:metadata-stage>
</match:request.type>

Summary

If your site contains a lot of static assets that aren't going to change for a long time or will never change for a unique URL, it may be worthwhile flagging them as immutable. This is especially useful if you expect your users to reload often as it removes the need for additional browser content re-validation. This results in improved performance and bandwidth consumption for the client.

Introducing all new Akamai OTA Updates, Check this out....!!

Launching this October @ EDGE 2017 

 

Akamai’s OTA Updates is a new performance product that provides fast delivery of software updates over the air to connected vehicles or devices. OTA Updates makes distributing software updates simple and secure for Auto OEMs by ensuring fast downloads to avoid costly recalls and warranty claims.

 

Why do we need OTA Updates?

Today’s vehicles incorporate software to operate and diagnose the engine and various systems within the car. This software needs updated regularly to maintain the function of the car as well as provide new functionality. Updating millions of vehicles that are seldom connected to Wi-Fi (with the car running) is a challenge. OTA Updates allows auto manufacturers to leverage the Akamai Intelligent platform to provide software updates to cars easily and securely so they can avoid recalls, warranty issues and service visits.

 

Use cases:

1. Deliver large files over the air, with throughput to complement cellular network traffic levels

  • Inherent Mobility (vehicles might not always be in range of good coverage)
  • Power Management (updates can only occur when car is on Run or On)

 

2. Robust, responsive patching system for updates to address vulnerabilities

  • Mutual authentication to secure communication between the servers and the vehicle
  • Authorization/authentication integrated with command/control

 

3. Replace an in-house service/software recall process

  • OTA vehicle upgrade will not only save consumers the frustration of a download or dealer visit, it will dramatically cut costs across the industry

 

4. Simply Reliability and Scalability challenges are offloaded

  • Enable OTA updates to thousands of vehicles across the product line and geographical locations, with greatly improved completion rates
  • Ability to introduce new features to the vehicles in instant time

  

Familiarize yourself with OTA Updates 

To better understand what OTA Updates solution is and what customer problems it solves, please review the product collaterals that’s available on IoT Products section.

 

Product Brief: OTA Updates

2-page overview to introduce prospects to OTA Updates. It’s available in following regional languages.  >> Learn More

OTA Updates Product Brief - English

OTA Updates Product Brief - Japanese

OTA Updates Product Brief - Korean

OTA Updates Product Brief - German

 

Product Description: OTA Updates

This copy contains more detailed information on Akamai OTA Updates Scale | Performance | Intelligence  >> Learn More

 

OTA Updates Product Description

 

Architecture Diagram: OTA Updates

The copy depicts the data flow and serves as the blueprint of the OTA updates architecture.

 >> Download Now

OTA Updates Architecture Diagram

 

If you tried to create a new certificate recently you may have notice there is a new cipher profile available called "ak-akamai-default-2017q3".

 

Just tested the new profile is compatible with HTTP/2 (h2), so enjoy!

 

For your reference, here is the list of ciphers included: (you can see the TLS 1.3 ciphers are preferred).

 

TLS13-AES-256-GCM-SHA384

TLS13-CHACHA20-POLY1305-SHA256

TLS13-AES-128-GCM-SHA256

TLS13-AES-128-CCM-8-SHA256

TLS13-AES-128-CCM-SHA256

ECDHE-ECDSA-AES256-GCM-SHA384

ECDHE-ECDSA-AES128-GCM-SHA256

ECDHE-RSA-AES256-GCM-SHA384

ECDHE-RSA-AES128-GCM-SHA256

ECDHE-ECDSA-CHACHA20-POLY1305

ECDHE-RSA-CHACHA20-POLY1305

ECDHE-ECDSA-AES256-SHA384

ECDHE-ECDSA-AES128-SHA256

ECDHE-RSA-AES256-SHA384

ECDHE-RSA-AES128-SHA256

ECDHE-RSA-AES256-SHA

ECDHE-RSA-AES128-SHA

AES256-GCM-SHA384

AES128-GCM-SHA256

AES256-SHA256

AES128-SHA256

AES256-SHA

AES128-SHA

As of 25 May 2017, the Beta of the new CPS is now open for all customers and partners. Direct customers with Web Performance products can enable Beta Channel via Marketplace in Luna today to gain access. Indirect Web Performance customers and customers of Media and Security products should work with their account teams to have the beta enabled for their contract.

 

Once enabled, you can access the beta in Luna, choose Configure -> Certificate Provisioning System (CPS) (Beta).

 

Update 18 September 2017: A new beta release of CPS is now available. All customers and partners enabled for, and using the beta will automatically gain access to these new features.

 

Features enabled in this third beta release:

  • View DV validation tokens and hostname status
  • Edit additional network deployment settings
    • OCSP Stapling, TLS protocol version selection, and Dual Stack RSA+ECDSA (when available on the specific certificate type being edited)

 

Features coming in a future release:

  • View history of certificate operations
  • Cancel in-progress operations
  • Save certificate information as drafts, to be edited later

 

 

Update 13 July 2017: A new beta release of CPS is now available. All customers and partners enabled for, and using the beta will automatically gain access to these new features.

 

Features enabled in this second beta release:

  • View and Modify existing certificates (SAN modifications)
  • Upload third-party certificates
  • Update network deployment settings while a certificate operation is in-progress
  • All the features listed below in previous beta releases

 


Update 30 May 2017: As of May 25, 2017, the Beta of the new CPS is now open for all customers and partners. This new version of our Certificate Provisioning System has been designed around a task-based interface which mirrors your own certificate provisioning workflows. CPS shows certificate activity happening in the system and even highlights certificates that need attention.


Features enabled in this first beta release:

  • All-new In Progress view on the landing page detailing certificates that have In Progress activity
    • new certificate requests, renewals, and modifications
    • highlights for certificate requests which need user attention
    • one-click access to certificate order status messages from our Certificate Authority partners
  • All-new Active view on the landing page detailing all your deployed certificates
    • call out of Staging versus Production deployments
  • Simplified search interface
  • All-new workflow for creating new certificates (DV, OV, EV, and third-party)
  • Download CSR for third-party certificates
  • Updated Certificate Detail view
  • Updated Network Deployment options view
  • Delete certificate functionality
  • In-line help with links to an updated online help reference
  • Faster, more responsive user experience
  • And many more features throughout the application

 

Features coming in a future release:

  • View DV validation tokens and status
  • View and Modify certificates (SAN modifications)
  • Upload third-party certificates


We will continue to update the application with additional features throughout the Beta. Both the new Beta application and the old application access the same back-end for certificate provisioning, so you can switch between them to access and modify all your certificates. Once the Beta is complete later this year, the old application will be decommissioned.

 

We encourage you to try out this new application. If you have feedback on this new beta capability, or have issues, please reach out to Akatec through your normal support channels. You can also follow this blog post to be notified when new Beta features are available.

 

 


 

Hello all. 

 

In March 2016, Akamai launched our Certificate Provisioning System (CPS) Self Service feature, enabling users to self-provision and manage their SSL/TLS certificates on Akamai’s Secure CDN.

 

 

Soon, we will launch a beta of an entirely new user experience for certificate provisioning. This new version has been designed based on your feedback we received over the last year, and focuses around a task-based interface. It shows certificate activity happening in the system and even highlights certificates that need attention.

 

 

Beta of the new CPS user experience will be open to all customers. Direct customers can enable Beta Channel via Marketplace in Luna today, and you will get access as soon as the Beta is open. Other customers should reach to their account team or Customer Care to have the Beta enabled.

 

 

Follow this blog post to be notified when the Beta is available.

Javier Garza

The Origin HTTP/2 Frame

Posted by Javier Garza Employee Sep 12, 2017

For you information there is a new draft being considered right now at the IETF group called The ORIGIN HTTP/2 Frame which (once approved) will allow a boost in performance when using connection coalescence to a given origin (the draft is co-authored by Akamai's Erik Nygren)

 

The HTTP/2 specification (RFC7540) allows clients to coalesce different origins (RFC6454) onto the same connection when certain conditions are met. However, a 421 status code is returned when a connection is not usable for a coalesced origin. Using a status code in this manner allows clients to recover from misdirected requests, with the drawback of adding latency. To address that, this specification defines a new HTTP/2 frame type, "ORIGIN", which allows servers to indicate what origins a connection is usable for.

Background on the Google/Symantec SubCA Transition

At the beginning of 2017, the Google Chrome team started investigating Symantec for mis-issuing certain TLS server certificates. Over the last five months, Google and Symantec have been working to restore the industry’s confidence in certificates issued by Symantec, including certificates under the GeoTrust, RapidSSL, and Thawte brands. As always, Akamai is in close contact with Symantec, our certificate partner, providing feedback on the proposals, and representing our customers’ interests.

 

Google and Symantec have now indicated that trust for certificates issued by Symantec from their existing PKI infrastructure will be phased out by the Google Chrome browser in two phases, April 2018 and October 2018. After these dates, Google Chrome (and other browsers that follow suit) will stop showing the “secure padlock” for sites presenting these certificates. They may even show “insecure site” warnings in the address bar or on error pages. All existing Symantec certificates need to be renewed on their new PKI infrastructure (available on or before December 1, 2017) to continue to be trusted in future versions of Google Chrome.

 

Akamai is committed to making this transition smooth for our customers. Most of the affected customer certificates will rotate automatically, before Chrome’s scheduled actions. In these cases, there is no action customers need to take. Some Akamai-managed customer certificates and some third-party (customer-managed) certificates will need to be rotated early. For these certificates, Akamai will shift the scheduled renewal start date to be several months before the Chrome distrust dates. This will give time for those certificates to be rotated before the scheduled distrust dates. In all cases, customers can choose to rotate their certificates early through CPS. See below for more details.

 

Affected Certificates

The upcoming changes, affect all certificates issued by Symantec. For Akamai customers, this includes:

  • All Akamai-managed Symantec OV Single, SAN, Wildcard, and Wildcard SAN certificates,
  • All Akamai-managed GeoTrust OV Single, SAN, and Wildcard certificates,
  • All Akamai-managed Symantec EV Single and SAN certificates, and
  • Some customer-managed third-party certificates.

 

Akamai-managed certificates issued by Comodo and Let’s Encrypt are not affected by these changes.

 

Distrust Schedule

Chrome 66 (beta in March 2018, stable April 2018) will no longer trust Symantec-issued certificates with a Not Before date of June 1, 2016 or prior.

  • No currently-valid Akamai-managed Symantec- or GeoTrust-branded OV certificates are affected by this phase out. All current Akamai-managed OV certificates were issued after June 1, 2016.
  • No currently-valid Akamai-managed Symantec-branded EV certificates are affected by this phase out. All current Akamai-managed EV certificates were issued after June 1, 2016.

 

Chrome 70 (beta in September 2018, stable October 2018) will no longer trust any Symantec-issued certificates issued prior to December 1, 2017, or from their old PKI infrastructure.

  • All Akamai-managed Symantec- and GeoTrust-branded OV certificates are affected by this phase out.
  • All Akamai-managed Symantec-branded EV certificates are affected by this phase out.

 

Google and Symantec have indicated that certificates issued by Symantec and GeoTrust after December 1, 2017 will be trusted in all planned future versions of Chrome.

 

New Trust Chains

Google and Symantec have indicated that all certificates issued after December 1, 2017 will be issued on a new PKI platform. New certificates will be issued with different trust chains (intermediate and root certificates) from those obtained today. Most customers will not notice this change as certificates issued with the new trust chains will continue to be trusted by existing browsers. This will be accomplished by providing a cross-signed root. For example, today Akamai obtains Symantec OV SAN certificates in this structure:

End-entity certificate
signed by the “G4 intermediate”:
C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4
signed by the “G5 root”:
C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5

 

When TLS clients connect to the Akamai edge servers, we send the end-entity certificate and the intermediate certificate to the connecting client. The root does not need to be sent (and should not be sent) to the connecting client as the root certificate is assumed to already be in the client’s trusted root store on the device or web browser. This way the client can construct a trust path from the end-entity certificate to a locally trusted root.

 

Akamai-managed OV SAN certificates issued by Symantec’s new PKI infrastructure after December 1, 2017 will have this structure:

End-entity certificate
signed by the new Symantec intermediate:
(DN still to be determined)
signed by the new Symantec root:
(DN still to be determined)
signed by the existing “G5 root”:
C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5

 

Akamai will send the end-entity certificate, the intermediate, and a cross-signed version of the new Symantec root to connecting clients. This trust chain will enable clients that have already added the new Symantec root to their trust stores to build a trust chain terminating in the new root that is in their trusted root store. It also enables clients which have not yet added the new root (or those that never will) to construct a trust path from the end-entity certificate to the existing trusted “G5” root.

 

Certificates with the legacy “Cross-signed 1k root” option enabled in CPS will see a new trust chain with this structure:

End-entity certificate
signed by the new Symantec intermediate:
(DN still to be determined)
signed by the new Symantec root:
(DN still to be determined)
signed by the existing “G5 root”:
C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
signed by the existing “1k root”:
C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

 

We recommend that customers move away from the 1k root as soon as possible. Most customers have no need for the 1k root as TLS clients have been upgraded to support the Default trust chain. This can be accomplished today in CPS by selecting the “Default” trust chain for your certificates.

 

Google and Symantec have indicated that Akamai customers should expect new trust chains for all Akamai-managed OV and EV certificate types, from both GeoTrust and Symantec. DigiCert has announced their intention to purchase Symantec’s PKI business. The root certificates in these new trust chains may be newly generated under the Symantec brand, or they may be an existing DigiCert root. These new trust chains have not yet been generated, and the industry has yet to receive them from Symantec. Once the complete trust chains are available, we will update this announcement, and post them on our Community page SSL/TLS certificate chains for Akamai-managed certificates.


What actions do customers need to take?

  • If your certificates were issued prior to June 1, 2016, they will need to be renewed prior to April 2018. We will reach directly to the affected customers and will start early renewal of these certificates in January 2018.
  • All currently-valid Akamai-managed OV certificates issued prior to October 2017 will automatically rotate on their regular schedule 60 days prior to expiration. This means that existing and future certificates, issued prior to October 2017, will all naturally expire prior to being distrusted in October 2018. Existing certificates will continue to be trusted by browsers until they are replaced with the newly issued certificates. No customer actions beyond responding to the validation emails and phone calls from Symantec are required.
  • All other Akamai-managed OV certificates issued between October 2017 and December 2017, as well as all Akamai-managed EV certificates, regardless of issuance date, will need to be renewed prior to October 2018. Starting in January 2018, we will be in touch with the affected customers. We intend to shift the renewal dates earlier for existing certificates so their replacements can be issued prior to the October 2018 distrust date.
  • The scheduled distrust of Symantec-issued certificates applies to all Symantec brands including GeoTrust, RapidSSL, and Thawte. Customers who have third-party certificates on the Akamai Secure CDN from these brands may also be affected by these changes. These third-party certificates can be renewed after December 1, 2017 by generating and downloading a CSR from our Certificate Provisioning System (CPS), and sending that CSR to Symantec to obtain a new certificate.
  • At any time, customers can force early renewal of their certificates (both Akamai-managed and third-party) by going into CPS and performing an “Edit and Submit” action for your certificate. We recommend waiting until after December 1, 2017 when certificates will be issued by Symantec’s new PKI infrastructure.

 

FAQ

Is there a cost or contract impact because of this change?

No, your current contracted rates remain intact. No additional Akamai paperwork is required.

 

Why is Akamai continuing to partner with Symantec for certificate issuance?

Symantec, and soon to be DigiCert, is the global leader in SSL/TLS certificate issuance. They continue to be the best fit for the needs of our customer base. As announced in April 2016, Symantec remains our strategic partner for issuance of OV and EV certificates.

 

What if I do not want an OV or EV certificate from Symantec?

Akamai offers fully managed and automated DV SAN certificates from Let’s Encrypt. We also offer a third-party solution that gives customers the ability to get an SSL certificate of any type from their provider of choice.

 

How will the sale of Symantec’s PKI business to DigiCert affect my certificates?

DigiCert’s parent company, Thoma Bravo, has announced their intention to acquire the Symantec PKI business in Q4 2017 (Symantec’s fiscal Q3 2018). Under current plans, this purchase will not impact the transition process outlined above. Even after the sale, customers with Akamai-managed OV and EV certificates will continue to use the same provisioning process as they do today, using CPS in our Luna portal. Google and Symantec have indicated certificates issued after December 1, 2017 on the new Symantec infrastructure will continue to be trusted until their expiration date.

 

My applications are sensitive to trust chain changes. What should I do?

Ensure that Change Management (“Test on Staging”) is turned on for your certificates in our Certificate Provisioning System (CPS). This feature will allow you to inspect and test new certificates in Staging prior to production deployment. Akamai strongly discourages customers from pinning certificates in their applications.

 

Can you provide the new trust chains before my certificate is rotated?

Akamai will post the new trust chains, including intermediate certificates and roots, once they are available, in our Community at SSL/TLS certificate chains for Akamai-managed certificates.

 

What if my applications require a 1k root like the one provided by the “C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority” root?

We recommend that customers move away from the 1k root as soon as possible. This can be accomplished today in CPS by selecting the “Default” trust chain for your certificates. Akamai will continue to offer a trust chain with a cross-signed 1k root certificate for Symantec OV customers. Please see above for more details.

 

Can I obtain a new Symantec certificate prior to December 2017?

Customers can reissue certificates at any time by going into CPS and performing an “edit and submit” action for your certificate. We recommend waiting until after December 1, 2017 when certificates will be issued by Symantec’s new PKI infrastructure.

 

Why is Akamai waiting for most certificates to expire and be replaced, instead of forcing early renewal after December 2017?

While we could initiate early renewals of all our customers’ Symantec certificates, we manage tens of thousands of certificates on our Secure CDN. It is better for everyone, including our customers, if the renewal dates for certificates are spread out throughout the year.

 

When my certificate request is submitted to Symantec after December 1, 2017, will I have to go through the OV or EV validation process again?

The exact validation steps at the time of certificate renewal will be determined by Symantec following the industry-standard CA/Browser Forum guidelines, and as further indicated by Symantec and Google.

 

I’m an existing GeoTrust customer. What happens to my GeoTrust certificate?

Customers with GeoTrust certificates, a Symantec brand, issued through Akamai will continue to be renewed on GeoTrust. All GeoTrust certificates issued prior to December 2017 will have to be replaced by October 2018 to continue to be trusted in the Chrome browser.

 

Can I convert my GeoTrust certificate to a Symantec SSL certificate?

Contact your account team to transition to the new certificate authority.

 

Is my DV SAN certificate from Let’s Encrypt impacted by this change?

Let’s Encrypt certificates are not impacted by these changes.

 

I still have an Akamai-managed EV certificate from Comodo. Is it impacted by this change?

Akamai-managed Comodo EV certificates are not impacted by these changes. As previously announced, existing Comodo certificates will be replaced with a Symantec certificate prior to current certificate expiration. If this scheduled renewal occurs prior to December 1, 2017, the resulting Symantec certificate will need to be renewed prior to October 2018.

 

Is my third-party certificate impacted by this change?

Customers who have third-party certificates on the Akamai Secure CDN from GeoTrust, RapidSSL, Symantec, and Thawte may be affected. Customers can replace these third-party certificates after December 1, 2017 by generating and downloading a CSR from our Certificate Provisioning System (CPS), and sending that CSR to Symantec to obtain a new certificate.

 

Is the trust chain of the Akamai shared certificate changing?

The trust chain of the “a248” shared certificates used for the a248.e.akamai.net, *.akamaihd.net, *.akamaihd-staging.net, *.akamaized.net, and *.akamaized-staging.net hostnames will change in line with the directions from Google and Symantec. We will post the new certificates on our Community page SSL/TLS certificate chains for the Akamai shared certificate when they are available.

 

My origin server has a certificate issued by Symantec. When will Akamai distrust this certificate?

Akamai will continue to trust Symantec certificates for connections from the Akamai Secure CDN to origin servers until those certificates expire.

 

 

If you any additional questions about this transition, please reach out to your Account Team or Akamai Technical Support.

Ever struggled getting to Akamai Staging?

 

Hereby I list out the test instructions for Akamai and how to test the configuration on the Akamai Staging environment. Please go through this carefully, it should explain it all. If there are any questions at all, please let me know and I can assist you further to test properly!

 

REQUIREMENTS FOR TESTING

  1. Administrator rights to change the HOSTS-file on the Operating System.
    • Please make sure not to test through a VPN, it might override your local HOSTS-file.
  2. Able to perform dig/ping commands.
    • Mac: Terminal or Windows: Command Prompt.
  3. Internet Browser.
    • Google Chrome is recommended and these instructions will share details on all the necessary plugins.

 

WHAT IS AKAMAI STAGING?

Within Akamai, we have two environments, the Akamai Staging and Akamai Production environments. Outside of several minor differences, both act similar. The Akamai Staging network is a small set of EdgeServers and is used of testing configurations. Please understand the Akamai Staging environment is only for functional testing and not meant for performance testing.

 

 

STEP 1: GET AN AKAMAI EDGESERVER IP-ADDRESS

To be able to test a configuration on the Akamai Staging network, a tester is required to spoof his or her HOSTS file to send end-user request for a particular domain/hostname to an Akamai Staging EdgeServer.

 

Due to our ever-changing set of Staging EdgeServers and the way our platform works, I recommend requesting a “fresh" Staging IP-address for each test. It is important to use the Staging EdgeHostname. You can use your given EdgeHostname and just add –staging to the end. Please refer to the other email with your specific EdgeHostnames.

 

So:

Www.akamai.com.edgesuite.net becomes:

Www.akamai.com.edgesuite-staging.net

 

You can find out the Akamai IP-address by doing either a dig or ping command. See below:

 

COMMAND:

dig www.akamai.com.edgesuite-staging.net

RESULT:

www.akamai.com.edgesuite-staging.net. - 21600 - IN - CNAME - a1407.r.akamai–staging.net.

a1407.r.akamai-staging.net. - 20 – IN – A - 195.59.188.153

 

As you can see, the EdgeHostname is mapped on a DNS level to our Akamai DNS servers who will then dynamically map the end-user/tester to the nearest EdgeServer.

 

NOTE: If you are using ChinaCDN, GTM or HD Streaming, please refer to the instructions below as retrieving a Staging IP works a little bit different.

 

 

STEP 2: SPOOF BY MODIFYING THE HOSTS FILE

Now this IP-address needs to be added to the HOSTS-file of the Operating System. For Windows: C:\system32\drivers\etc\hosts and for MAC OS: etc/hosts.

 

Once you open this file in a text processor like Notepad, you can add the following line:

195.59.188.153 www.akamai.com

 

After saving the file, please do a ping-command to the website to verify that the correct Akamai IP-address is used.

 

 

STEP 3: PREPARE YOUR BROWSER FOR TESTING

I recommend using Google Chrome for testing. Google Chrome has Developer Tools built in that can return a lot of useful diagnostic information regarding testing including Akamai information. With a plug-in to Modify HTTP Headers, you will soon be ready for testing!

 

 

STEP 3A: INSTALLING MODIFY HEADERS FOR GOOGLE CHROME

In order to modify HTTP headers and add the Akamai Pragma headers for feed please install Modify Headers. You can find it here.

https://chrome.google.com/webstore/detail/modify-headers-for-google/innpjfdalfhpcoinfnehdnbkglpmogdi

 

 

STEP3B: SET-UP MODIFY HEADERS WITH AKAMAI PRAGMA HEADERS

In order to set-up the Akamai Headers, please follow these steps.

  1. Go to your browser
  2. Click on the ‘head’ icon in the top right corner. This should open the Modify Headers plugin.
  3. Click on the ‘blue +’ sign in the top right corner to add the Akamai headers.
  4. Choose ‘Add’ in the Action column.
  5. Type in Pragma in the Name column.
  6. Copy the following in the Value column.
    • akamai-x-cache-on, akamai-x-cache-remote-on, akamai-x-check-cacheable, akamai-x-get-cache-key, akamai-x-get-extracted-values, akamai-x-get-nonces, akamai-x-get-true-cache-key, akamai-x-get-client-ip
  7. (optional) Add a description in the Description column.
  8. Click on the ‘green floppy’ icon to save it.
  9. Make sure the ‘green ON’ symbol is active under the Actions column.
  10. Click on the ‘green Play’ button in the top left corner to start Modify Headers.

 

STEP 3C: OPEN A NEW TAB AND ENABLE DEVELOPER TOOLS

In order to start testing, open a new tab in Google Chrome. By right-clicking, you should see a list of option, select Inspect Element.

 

This should open the Developer Tools. There are a lot of options but please click on the Network tab. The Network tab will show you each object being retrieved from a HTTP request with the additional headers.

 

 

STEP 4: TIME TO START BROWSER/FUNCTIONAL TESTING

Now everything is in order to start testing configuration on the Akamai Staging network. By using the browser of choice, go to the domains you want to test. The Akamai Staging EdgeServer receives the request and based on the hostname will use the correct configuration that is deployed on the staging platform. Caching, Site Delivery and all other Akamai configured features will then be taken in effect and the end-user request is forwarded to the Origin Server as configured.

 

You can now test all the changes made to the configuration and verify if everything is working accordingly. Once approved, the configuration can be deployed to the Akamai Production platform.

 

 

STEP 4A: HOW TO VERIFY YOU ARE TESTING ON AKAMAI STAGING?

In the Developer Tools, Network tab, please click on the top-object. Usually this is the website you are trying to contact. By looking in the Header information, a header X-Akamai-Staging should be present. If this header is present, you are correctly testing through the Akamai Staging platform.

 

More Akamai headers should be returned that shows input on the features enabled and if objects are correctly being cached. If you have any questions about this, please feel free to let me know!

 

 

STEP 5: TEST RESULTS

If there are any issues found, please send me the URL or how to navigate to that page and also the browser you tested it with. I will test this as well.

 

Please go through the website carefully, if all goes well, there should be no issues. This includes any special requirements like geo-routing, mobile routing etc. But also correct caching of items.

 

 

ADDENDUM - STAGING IP FOR CHINACDN / GTM / HD STREAMING CUSTOMERS

 

Procedure for Global Traffic Manager customers

There's a chance that the customer is using Global Traffic Management and when following the previous steps and in order to identify this possibility, the behavior will be that the results will show the same IP Address either for Production or Staging. 

To request the proper Staging IP addresses, the lookup queries need to be done against the serial+maprule host. The process is the following:
 

1) Example of request results when customers have GTM on their domain (Note that the results point to the same IP Address):
$ dig www.foo.com
;; ANSWER SECTION:
www.foo.com.        60    IN    CNAME    www.foo.com.edgekey.net.
www.foo.com.edgekey.net. 21600 IN CNAME www.foo.com.edgekey.net.globalredir.akadns.net.
www.foo.com.edgekey.net.globalredir.akadns.net. 3600    IN CNAME e1234.b.akamaiedge.net.
e1234.b.akamaiedge.net.    20    IN    A    23.57.80.137

 

$ dig www.foo.com.edgekey-staging.net
;; ANSWER SECTION:
www.foo.com.edgekey-staging.net. 21600 IN CNAME    www.foo.com.edgekey.net.globalredir.akadns.net.
www.foo.com.edgekey.net.globalredir.akadns.net.    3600 IN    CNAME e1234.b.akamaiedge.net.
e1234.b.akamaiedge.net.    20    IN    A    23.57.80.137

2) From the previous results take the serial+maprule host (e1234.b.akamaiedge.net) and run a lookup by adding "-staging" to the domain:
$ dig e1234.b.akamaiedge.net
;; ANSWER SECTION:
e1234.b.akamaiedge.net.    20    IN    A    23.57.80.137

 

$ dig e1234.b.akamaiedge-staging.net
;; ANSWER SECTION:
e1234.b.akamaiedge-staging.net.    20 IN    A    72.247.167.214 <=== IP Address of Staging

3) Proceed by using the resulting IP address to do the spoof of www.foo.com on the hosts file as stated in the general procedure.

Procedure for ChinaCDN

If you are trying to perform functional or A/B testing for users in China on a property subscribed to China CDN Service, KB 4651describes special considerations for that testing scenario.

Procedure for HD Streaming

For HD streaming configurations, the staging hostname (*.akamaihd-staging.net) is added to the configuration by default. Therefore, you may request the staging property directly, which is CNAMEd to staging network.

Prateek Waghre

ICP Framework Updates

Posted by Prateek Waghre Employee Aug 22, 2017

Background

In 2005, MIIT issued regulations for Non Commercial Internet Content/Information Provider and stated that any internet content/information provider was not allowed to provide internet content service without a valid ICP Beian filed in the MIIT’s ICP system. Since then, the ICP Beian has been a mandatory requirement for all ChinaCDN customers.

With the internet industry and CDNs being relatively new to China at the time, to foster industry growth, the authorities did not strictly enforce the local hosting requirement during the ICP Beian process and with consent from the local authorities, ChinaCDN was able to provide this solution to all ChinaCDN global customers.

 

From 2016 onwards, a series of enforcement notices (see links 1, 2 and 3 below) have collectively stated that organizations who intend to serve their websites to end users in China must do so from servers located within China, and are required to setup hosting under the domain with a China based ISP.

So, what is happening now?

In July 2017, the MIIT further clarified that CDN services are strictly prohibited without a valid ICP (see link 3 below). As such, the government has signaled their intention to more strictly regulate how it issues and enforces the use of ICP Beian. Akamai and its partners in China agree that these requirements will affect customers with existing ICP Beian as well as those looking to procure new ICP Beian.

 

Due to this stricter enforcement of the ICP registration rules by MIIT, customers need to host  the domain’s www hostname, with a licensed hosting service provider in China. e.g. www.company.com to obtain an ICP for company.com.

What does this mean for new and existing ICP registrations?

Any new ICP Beian applications or updates to existing ICP records will require the www domain of the TLD in question to be hosted locally in China(eg. www.company.cn or www.company.com). Any sub-domain of the TLD other than the www, will not suffice. Content can be delivered on an alternate domain (eg. content.company.cn or content.company.com) which can be hosted at a global data center located outside of China.

 

Customers that previously procured their ICP Beian registration via Akamai’s partner relationships also need to update their existing ICP Beian records with local hosting provider information before the end of November 2017. If you do not have a preferred hosting provider in China, Akamai will be happy to facilitate discussions with its partners.

 

Please contact your Akamai account team  to understand if your ICP registration is affected and guidance on possible next steps.

 

If you are not aware of your account team’s contact information you can obtain this information from Luna Control Center (Support > Contact Support > More Help > Akamai Team for …...).

If you do not see this option in Luna, please reach out to your PoC at the Akamai partner through which Akamai services have been procured and request them to put you in touch with your Akamai team.

 

Links (in Chinese)

  1. http://www.beian123.org.cn/news.php?id=1383
  2. http://www.miit.gov.cn/n1146295/n1652858/n1652930/n3757020/c5402051/content.html
  3. http://www.miit.gov.cn/n1146285/n1146352/n3054355/n3057709/n3057714/c5717035/content.html

What is Brotli?

Brotli is the name of a Swiss bakery product, a small, often round loaf of bread. However, we are not here to talk about that! Brotli is also a generic-purpose lossless compression algorithm developed by Google in 2015. It compresses data with a combination of the LZ77 algorithm and Huffman coding. Since then, major browsers have widely adopted this compression method, including Google Chrome, Microsoft Edge, Mozilla Firefox, Opera, and Safari.

 

Benefits of Brotli

Brotli algorithm is similar to Deflate in speed but offers denser compression. Its compression ratio is also considerably better than Gzip. Based on Google's summary in 2016:

 

  • Brotli outperforms gzip for typical web assets (e.g. CSS, HTML, JS) by 17-25%.
  • Brotli -11 density compared to gzip -9.
  • HTML (multi-language corpus): 25% savings.
  • JS (Alexa Top 10k): 17% savings.
  • Minified JS (Alexa Top 10k) 17% savings.
  • CSS (Alexa Top 10k): 20% savings.

 

*Alexa Top 10k refers to the top 10,000 sites ranked by one month of traffic according to www.alexa.com.

 

Brotli Enablement

So, how do we start using this feature? There are two ways to utilize Brotli in Akamai configurations.

  1. Resource Optimizer module: Akamai compresses the content with Brotli encoding on the edge.
  2. Brotli Support module: Akamai passes on and caches already Brotli-compressed content from the origins.

 

Let's take a look at each one of the modules in detail.

 

Resource Optimizer

What is it?

Resource Optimizer automates the compression and delivery of cached resources for websites and mobile apps, to decrease bandwidth and improve the web experience. Resource Optimizers uses Brotli and Zopfli compression to shrink resources from 5% to 15% over GZIP and delivers the smallest version depending on browser support.


How to add the module?

The Resource Optimizer module is a part of the Adaptive Acceleration feature in the ION Beta Channel. You need to upgrade the configuration to use ION Beta Channel to see this contract line item. You can add this in the Market Place on Luna or reach out to your account team for help.

 

 

Brotli Support

What is it?

When enabled, this module allows the configuration to return Brotli-compressed assets from our customers' origins and cache them on edge servers. When both the Brotli Support and LMA modules are enabled, Akamai caches both the GZIP and Brotli versions of the resource.


How to add the module?

Currently, the module is available for all accounts that have added the beta channel to their delivery product. Please reach out to your account team for enablement details.

(Unlike Resource Optimizer, the product type does not have to be ION for Brotli Support Enablement.)

Long waiting line

 

 

HTTP Head of line blocking

 

Head of Line blocking (in HTTP/1.1 terms) is often referring to the fact that each client has a limited number of TCP connections to a server (usually 6 connections per hostname) and doing a new request over one of those connections has to wait for the previous request on the same connection to complete before the client can make a new request.

 

HTTP/1.1 introduced a feature called "Pipelining" which allowed a client sending several HTTP requests over the same TCP connection. However HTTP/1.1 still required the responses to arrive in order so it didn't really solved the HOL issue and as of today it is not widely adopted.

 

HTTP/2 (h2) solves the HOL issue by means of multiplexing requests over the same TCP connection, so a client can make multiple requests to a server without having to wait for the previous ones to complete as the responses can arrive in any order.

 

TCP slows down HTTP/2

 

HTTP/2 does however still suffer from another type of HOL, as it runs over a TCP connection; and due to TCP's congestion control, one lost packet in the TCP stream makes all streams wait until that package is re-transmitted and received.

 

The obvious solution would be to run HTTP/2 over UDP + an optimized way of managing congestion, and that's precisely what the QUIC protocol does, so stay tuned for what the future of the HTTP protocol will be!

 

This and more, are explained in the Learning HTTP/2 O'Reiily book

 

 

Disclaimer: The content of this blog is based on a Stack Overflow post authored by Daniel Stenberg, a well known HTTP/2 expert and the main developer of the awesome curl command line utility

On September 30, 2017, Akamai will be adding IPv6 delegations to Global Traffic Manager (GTM).

The vast majority of recursive DNS resolvers (such as those at an ISP, a large enterprise, or a public provider such as Google Public DNS) are "dual-stacked", meaning they can connect to authoritative nameservers (such as Akamai's GTM servers) over IPv4 or IPv6.  Previously, Akamai separated IPv6 GTM domains into the akadns6.net domain (which has IPv6-only delegations), and the vast majority of GTM users were under the akadns.net domain, which has IPv4-only delegations.  To bring GTM in line with our other DNS products (such as FastDNS), we will be adding IPv6 delegations to akadns.net on September 30 2017.  No changes are being made to the akadns6.net domain at this time.

Which GTM domains are affected?

A GTM domain is affected if ALL of the following are true:

  • The GTM domain contains at least one CIDR-mapped property that is currently in use
  • The CIDR maps for that property do not currently contain IPv6 addresses
  • End users who access the CIDR-mapped property may do so using a recursive resolver that has IPv6 connectivity.  (All major public DNS providers (Google, OpenDNS) have IPv6 connectivity, as do the majority of the largest ISPs in the United States and Europe).

 

Properties that use Geographic Mapping or AS (Autonomous System) mapping are NOT affected by this change.

Failover, Weighted Hashed, Weighted Round-Robin, Performance, and Load Feedback properties are NOT affected by this change.

What change must be made?

By September 30, 2017,  if you are affected (see above) , you must inspect your CIDR maps, and determine if IPv6 addresses need to be added.  If any necessary IPv6 addresses are not added by September 30, 2017, some end users who were previously sent to a CIDR-specific datacenter may be sent to the default datacenter (indicated as "All Other CIDRs" in Luna) if they use a recursive resolver with IPv6 connectivity.

How to determine which IPv6 addresses to add?

There is no way to automatically determine an IPv6 address given an IPv4 address.  You will need to identify the owners of the IPv4 space , and get the corresponding IPv6 CIDRs from the owners.

NOTE: If the only entry in any given CIDR map is a single datacenter, with CIDRs that are "127.0.0.1" or "127.0.0.0/8", then no update is needed for that CIDR map.  That is the "localhost" IP address, which should never be visible on the public internet. 

Examples

Example: ACME Corp has the acme.biz.akadns.net GTM domain, and the property "www".  They use a CIDR map so that users in their offices or on their VPN will be sent to the internal website, and other users will be sent to their external website.  They have a CIDR map, indicating that traffic from 1.2.3.0/24 and 5.6.7.0/26 will be sent to their internal datacenter, and all other traffic will be sent to their external datacenter.  They maintain their own recursive resolvers that employees are required to use, and do not have IPv6 connectivity.

Action needed: None.  No change is needed, since the CIDR-mapped property is only intended to be used by their employees, and their corporate resolver does not have IPv6 connectivity.

Example: WidgetCo has the domain "widgets.biz.akadns.net", and the property "customer".  They have a partnership with an ISP, GlobalNetCom.  They use a CIDR map so that GlobalNetCom end-users get sent to a specific re-branded customer portal, and all other end users get sent to their default portal.  Currently, the CIDR map for GlobalNetCom only contains 250.1.2.0/24 and 250.2.0.0/16.   However, GlobalNetCom recursive resolvers have both IPv4 and IPv6 connectivity

Action needed: WidgetCo will need to contact GlobalNetCom, and find out what their IPv6 space is.  Once they have that information, they'll need to update the CIDR map to include that IPv6 space (e.g. 2002::ffff:0000/120).  If that change is not made, GlobalNetCom end users using IPv6 would be sent to the default customer portal, rather than the specific re-branded one.

Customer may require to use Global traffic management (GTM) to balance load between two or more servers in a cloud, such as Amazon's EC2 or AWS ELB service. The provider provides a hostname for each cloud region that resolves to one or more virtual machines (VM) in the region.

 

For example, with Amazon AWS ELB service, as load changes, the service creates or destroys VMs as needed and thus results in hostname resolution changing frequently to reflect the new VM.

 

GTM was originally designed to load balance between datacenters with static IP address and not between VM environments or cloud based services which needs to be load balanced between changing IP addresses. By default our monitoring agents probe each datacentre based on the frequency of the liveness test configured; however only does a DNS lookup on the datacentre hostnames every 15 minutes irrespective of the DNS TTL associated.

 

This may pose a problem if the IP address to which Akamai liveness test has been taken down or replaced with another virtual machine within the 15 minutes default DNS lookup frequency on our agents.

 

In order to have GTM liveness test agents do a hostname resolution at the test time, customers will need to enable "Cloud Server Targeting" at the Data centre.

 

Steps to enable the "Cloud Server Targeting"  feature

 

1. Login to Luna Control Center

2. Go to Configure --> Traffic Management --> Configuration

3. Click on the domain which is used to load balance between Cloud based services

4. Go to "Data Centers" section and click on the respective Data centers used for the GTM domain

5. Enable the check box next to "Cloud Server Targeting"

 

More details on GTM is available on Luna Control Center --> Support --> User and Development Guides --> Traffic Management

Hi all,

 

The Learning HTTP/2 book authored by Stephen Ludin and Javier Garza is fully available since June 2017

 

You can get a copy of the book at Amazon.com, O'Reilly's Website, or read it online with an O'Reilly Safari subscription.

 

Here is the table of Contents:

  • Chapter 1 The Evolution of HTTP
  • Chapter 2 HTTP/2 Quick Start
  • Chapter 3 How and Why We Hack the Web
  • Chapter 4 Transition to HTTP/2
  • Chapter 5 The HTTP/2 Protocol
  • Chapter 6 HTTP/2 Performance
  • Chapter 7 HTTP/2 Implementations
  • Chapter 8 Debugging h2
  • Chapter 9 What's next?
  • Appendix A HTTP/2 Frames
  • Appendix B Tools Reference

 

Learning HTTP/2 book cover

 

Happy reading!

 

Javier

Filter Blog

By date: By tag: