$30 off During Our Annual Pro Sale. View Details »

Hooked on HTTP/2

Hooked on HTTP/2

Introduction to gRPC. Including HTTP/2 and Protocol Buffers. Delivered by Mandy Waite at Endpoint Conference 2015 (#endpointcon)

GoogleCloudPlatform

September 04, 2015
Tweet

More Decks by GoogleCloudPlatform

Other Decks in Technology

Transcript

  1. Microservices development with gRPC
    Hooked on HTTP/2

    View Slide

  2. @grpcio @tekgrrl
    Mandy Waite
    Developer Advocate
    +MandyWaite
    @tekgrrl

    View Slide

  3. @grpcio @tekgrrl
    Hooked on HTTP/2
    Protocol Buffers
    gRPC
    Clients & Microservices
    1
    2
    3
    4
    Agenda

    View Slide

  4. HTTP/2

    View Slide

  5. @grpcio @tekgrrl
    So what’s up with HTTP/1?
    Today statistics show that there are on
    average:
    ● 12 distinct hosts per page
    ● 78 distinct requests per page
    ● 1,232 KB transferred per page
    Resulting in typical render times of 2.6-5.6 seconds
    (50th and 90th percentiles).

    View Slide

  6. @grpcio @tekgrrl
    HTTP Pipelining
    ● Queue responses not requests
    Domain Sharding
    ● Need more than 6 connections
    per origin? Add more origins!
    Concatenation and Spriting
    ● Multiple JavaScript/CSS/Image files
    combined into a single resource
    Resource Inlining
    ● Inline JS/CSS/Images in the page
    Coping Strategies
    img1.example.com
    img2.example.com
    img3.example.com
    ...

    View Slide

  7. @grpcio @tekgrrl
    HTTP Pipelining
    ● Head of Line blocking
    Domain Sharding
    ● Over sharding can kill
    performance
    Concatenation and Spriting
    ● Increased complexity, can hurt
    cache performance and page load
    Resource Inlining
    ● Can hurt cache performance, hard
    to get granularity right
    Copying Strategies - The downsides
    img1.example.com
    img2.example.com
    img3.example.com
    ...

    View Slide

  8. ● Improve end-user perceived latency
    ● Address the "head of line blocking"
    ● Not require multiple connections
    ● Retain the semantics of HTTP/1.1
    "HTTP/2 is a protocol designed for low-
    latency transport of content
    over the World Wide Web"

    View Slide

  9. @grpcio @tekgrrl
    ● One TCP connection
    ● Request → Stream
    ○ Streams are multiplexed
    ○ Streams are prioritized
    ● Binary framing layer
    ○ Prioritization
    ○ Flow control
    ○ Server push
    ● Header compression
    HTTP/2 in one slide…

    View Slide

  10. “... we’re not replacing all of HTTP — the
    methods, status codes, and most of the
    headers you use today will be the same.
    Instead, we’re redefining how it gets used
    “on the wire” so it’s more efficient, and so
    that it is more gentle to the Internet itself ....”
    - Mark Nottingham (HTTPbis chair)

    View Slide

  11. @grpcio @tekgrrl
    HTTP/2 binary framing 101
    ● Sits between Socket interface and
    the API
    ● HTTP messages are decomposed
    into one or more frames
    ○ HEADERS for meta-data
    ○ DATA for payload
    ○ RST_STREAM to cancel
    ○ …
    ● Each frame has a common header
    ○ 9-byte, length prefixed
    ○ Easy and efficient to parse

    View Slide

  12. @grpcio @tekgrrl
    Basic data flow in HTTP 2.0...

    View Slide

  13. @grpcio @tekgrrl
    Basic data flow in HTTP 2.0...
    Streams are multiplexed, because
    frames can be interleaved
    All frames (e.g. HEADERS, DATA, etc)
    are sent over single TCP connection
    Frame delivery is prioritized based on
    stream dependencies and weights
    DATA frames are subject to per-stream
    and connection flow control

    View Slide

  14. @grpcio @tekgrrl
    ● Each stream can have a weight
    ○ [1-256] integer value
    ● Each stream can have a
    dependency
    ○ parent is another stream ID
    Stream prioritization in HTTP/2...
    1. E.g.. style.css (“A”) should get 2/3rd’s of available resources as compared to logo.jpg (“B”)
    2. E.g.. product-photo-1.jpg (“D”) should be delivered before product-photo-2.jpg (“C”)

    View Slide

  15. @grpcio @tekgrrl
    Examples
    NOTE: Prioritization is an advisory optimization hint to the server

    View Slide

  16. @grpcio @tekgrrl
    HTTP/2 server: “You asked for
    /product/123, I know you’ll also need
    app.js and product-photo-1.jpg, so… I
    promise to deliver these to you, no
    need to ask for them. That is, unless
    you decline or cancel.”
    GET /product/123
    /product/123
    /app.js
    /product-photo-1.jpg
    ● Server push is optional and can be disabled by the client
    ● Server push is subject to flow control - e.g. “you can only push 5Kb”
    ● Pushed resources can be cached and prioritized individually
    Server push, “because you’ll also need…”

    View Slide

  17. @grpcio @tekgrrl
    HTTP/2 client: “I want photo.jpg,
    please send the first 20KB.”
    HTTP/2 server: “Ok, 20KB… pausing
    stream until you tell me to send more.”
    HTTP/2 client: “Send me the rest now.”
    GET /product-photo.jpg
    /product-photo.jpg
    /product-photo.jpg
    WINDOW_UPDATE
    ● Flow control allows the client to pause stream delivery, and resume it later
    ● Flow control is a “credit-based” scheme
    ○ Sending DATA frames decrements the window
    ○ WINDOW_UPDATE frames update the window
    Per-stream flow control

    View Slide

  18. @grpcio @tekgrrl
    HPACK header compression
    ● Literal values are (optionally) encoded with a static Huffman code
    ● Previously sent values are (optionally) indexed
    ○ e.g. “2” in above example expands to “method: GET”

    View Slide

  19. Protocol Buffers

    View Slide

  20. @grpcio @tekgrrl
    What are Protocol Buffers?
    Structured representation of data
    Google's lingua franca for data
    ● 48k+ Message Types
    ● 12k+ Proto files
    Evolutionary Development
    Incrementally solved problems, Now
    used for:
    ● RPC Systems
    ● Persistent Data Storage

    View Slide

  21. @grpcio @tekgrrl
    Protocol buffers:
    ● Efficient and compact binary data
    representation
    ● Clear compatibility rules; can
    easily be extended over time
    ● Generates idiomatic, easy to use
    classes for many languages
    ● Strongly typed; less error prone
    Why Protocol Buffers?

    View Slide

  22. @grpcio @tekgrrl
    Protocol Buffers also are:
    ● No use as a markup language
    ● Not human readable (native
    format)
    ● Only meaningful if you have the
    message definition
    Why not?

    View Slide

  23. @grpcio @tekgrrl
    Uniquely numbered fields
    Typed
    Hierarchical Structure
    Optional and Repeated fields
    Extensible without breaking backward
    compatibility
    Message Format (proto2)
    message Person {
    required string name = 1;
    required int32 id = 2;
    optional string email = 3;
    enum PhoneType {
    MOBILE = 0;
    HOME = 1;
    WORK = 2;
    }
    message PhoneNumber {
    required string number = 1;
    optional PhoneType type = 2 [default = HOME];
    }
    repeated PhoneNumber phone = 4;
    }

    View Slide

  24. @grpcio @tekgrrl
    Protocol Buffers language version 3
    Specified by syntax = “proto3”;
    proto2 continues to be supported
    All fields are optional in proto3
    No user specified default values
    No groups (FYI for those that use them)
    Message Format (proto3) syntax = “proto3”;
    message Person {
    string name = 1;
    int32 id = 2;
    string email = 3;
    enum PhoneType {
    MOBILE = 0;
    HOME = 1;
    WORK = 2;
    }
    message PhoneNumber {
    string number = 1;
    PhoneType type = 2;
    }
    repeated PhoneNumber phone = 4;
    }

    View Slide

  25. @grpcio @tekgrrl
    Add new fields without breaking
    backwards-compatibility
    old implementations ignore the new
    fields when parsing
    In proto3 any field can be removed, but
    don’t renumber existing fields
    Extensible
    syntax = “proto3”;
    message Person {
    string name = 1;
    int32 id = 2;
    string email = 3;
    address addr = 4;
    message address {
    string firstLine = 1;
    string secondLine = 2;
    string postalCode = 3;
    string country = 4;
    }
    ...
    }

    View Slide

  26. @grpcio @tekgrrl
    https://github.com/google/protobuf
    Protocol Buffer Compiler

    View Slide

  27. gRPC

    View Slide

  28. gRPC goals
    Enable developers to
    build micro-
    service-based
    applications
    Build an open source, standards-based, best-of-breed, feature-rich RPC system
    Create easy-to-use,
    efficient and idiomatic
    libraries
    micro-services
    performant and scalable
    efficient and idiomatic
    Provide a performant
    and scalable RPC
    framework

    View Slide

  29. @grpcio @tekgrrl
    IDL to describe the API
    Automatically generated servers and
    clients in 10+ languages
    Takes advantage of feature set of
    HTTP/2
    Lightweight open connections
    Point to point
    Streaming! Bidirectional streaming!
    gRPC in a nutshell

    View Slide

  30. @grpcio @tekgrrl
    gRPC client/server architecture

    View Slide

  31. @grpcio @tekgrrl
    Getting Started
    Define a service in a .proto file using
    Protocol Buffers IDL
    Generate server and client code using
    the protocol buffer compiler
    Use the gRPC API to write a simple
    client and server for your service in the
    languages of your choice

    View Slide

  32. @grpcio @tekgrrl
    service RouteGuide {
    rpc GetFeature(Point) returns (Feature);
    }
    message Point {
    int32 latitude = 1;
    int32 longitude = 2;
    }
    message Feature {
    string name = 1;
    Point location = 2;
    }
    Service Definition

    View Slide

  33. @grpcio @tekgrrl
    RPC Messages
    The most common use-case is a unary request-response RPC
    Msg1
    MsgA
    Client Server

    View Slide

  34. @grpcio @tekgrrl
    service RouteGuide {
    rpc GetFeature(Point) returns (Feature);
    }
    message Point {
    int32 latitude = 1;
    int32 longitude = 2;
    }
    message Feature {
    string name = 1;
    Point location = 2;
    }
    Unary RPC Definition

    View Slide

  35. @grpcio @tekgrrl
    RPCs and Metadata
    Metadata mechanism for extensibility
    Msg1
    MsgA
    Metadata
    Client Server
    Metadata

    View Slide

  36. @grpcio @tekgrrl
    Ordered Bidirectional Streaming RPC
    Msg1
    Msg2
    Msg3
    MsgA MsgB
    Metadata
    Metadata Metadata
    Client Server
    The second most common use-case is sending multiple request or response
    messages in the context of a single RPC call

    View Slide

  37. @grpcio @tekgrrl
    service RouteGuide {
    rpc ListFeatures (Rectangle) returns (stream Features);
    ...
    }
    message Rectangle {
    Point lo = 1;
    Point hi = 2;
    }
    Server Streaming RPC Definition

    View Slide

  38. @grpcio @tekgrrl
    service RouteGuide {
    rpc RecordRoute (stream Point) returns (RouteSummary);
    ...
    }
    message RouteSummary {
    int32 point_count = 1;
    int32 feature_count = 2;
    int32 distance = 3;
    int32 elapsed_time = 4;
    }
    Client Streaming RPC Definition

    View Slide

  39. @grpcio @tekgrrl
    service RouteGuide {
    rpc RouteChat (stream RouteNote) returns (stream RouteNote);
    ...
    }
    message RouteNote {
    string location = 1;
    string message = 2;
    }
    Bidirectional Streaming RPC Definition

    View Slide

  40. @grpcio @tekgrrl
    gRPC Language Support
    Implementations
    ● C core
    ○ Native bindings in C++, Node.js, Python, Ruby, ObjC,
    PHP, C#
    ● Java using Netty or OkHttp (+ inProcess for testing)
    ● Go

    View Slide

  41. @grpcio @tekgrrl
    channel = NettyChannelBuilder.forAddress(host, port)
    .negotiationType(NegotiationType.PLAINTEXT)
    .build();
    Channel Setup (Java Client)

    View Slide

  42. @grpcio @tekgrrl
    channel = NettyChannelBuilder.forAddress(host, port)
    .negotiationType(NegotiationType.PLAINTEXT)
    .build();
    blockingStub = RouteGuideGrpc.newBlockingStub(channel);
    asyncStub = RouteGuideGrpc.newStub(channel);
    Stub Creation (Java Client)

    View Slide

  43. @grpcio @tekgrrl
    channel = NettyChannelBuilder.forAddress(host, port)
    .negotiationType(NegotiationType.PLAINTEXT)
    .build();
    blockingStub = RouteGuideGrpc.newBlockingStub(channel);
    asyncStub = RouteGuideGrpc.newStub(channel);
    Point request =
    Point.newBuilder().setLatitude(lat).setLongitude(lon).build();
    Feature feature = blockingStub.getFeature(request);
    Unary Call (Java Client)

    View Slide

  44. @grpcio @tekgrrl
    @Override
    public void getFeature(Point request, StreamObserver responseObserver) {
    responseObserver.onValue(checkFeature(request));
    responseObserver.onCompleted();
    }
    private Feature checkFeature(Point location) {
    for (Feature feature : features) {
    if (feature.getLocation().getLatitude() == location.getLatitude()
    && feature.getLocation().getLongitude() == location.getLongitude()) {
    return feature;
    }
    }
    // No feature was found, return an unnamed feature.
    return Feature.newBuilder().setName("").setLocation(location).build();
    }
    Unary Call (Java Server)

    View Slide

  45. @grpcio @tekgrrl
    Authentication
    SSL/TLS
    gRPC has SSL/TLS integration and promotes the use of SSL/TLS to authenticate the
    server, and encrypt all the data exchanged between the client and the server.
    Optional mechanisms are available for clients to provide certificates to accomplish
    mutual authentication.
    OAuth 2.0
    gRPC provides a generic mechanism to attach metadata to requests and responses.
    Can be used to attach OAuth 2.0 Access Tokens to RPCs being made at a client.

    View Slide

  46. Microservices

    View Slide

  47. @grpcio @tekgrrl
    Decomposing Monolithic apps
    A B
    C D

    View Slide

  48. @grpcio @tekgrrl
    Decomposing Monolithic apps
    A B
    C
    D

    View Slide

  49. @grpcio @tekgrrl
    Decomposing Monolithic apps
    A B
    C
    D
    gRPC

    View Slide

  50. @grpcio @tekgrrl
    Freedom to pick the language independently for each micro-service, based on
    performance, library availability, team expertise etc
    MicroServices using gRPC
    Loosely coupled development
    Blocks of functionality can be broken off into separate MicroService. Allows
    organic growth
    Multi-language
    High Performance
    Make use of the strengths of HTTP/2 and Protocol Buffers

    View Slide

  51. @grpcio @tekgrrl
    Polyglot Microservices Architecture
    C++ Service
    gRPC server
    Golang Service
    gRPC server
    gRPC
    Stub
    Java Service
    gRPC
    Stub
    Python Service
    gRPC server
    gRPC
    Stub

    View Slide

  52. Mobile

    View Slide

  53. @grpcio @tekgrrl
    Abelana Mobile Sample App
    Photo-sharing App
    Mobile Clients communicate with gRPC
    endpoint
    Clients for iOS and Android
    https://cloud.google.com/solutions/mobile/image-management-mobile-apps-grpc

    View Slide

  54. @grpcio @tekgrrl
    Abelana Architecture
    @grpcio @tekgrrl

    View Slide

  55. Wrap-up

    View Slide

  56. @grpcio @tekgrrl
    grpc is Open Source
    We want your help!
    http://grpc.io/contribute
    https://github.com/grpc
    irc.freenode.net #grpc
    @grpcio
    [email protected]

    View Slide

  57. Hooked on HTTP/2

    View Slide