Receive the latest in our newsletter. More
Receive the latest in our newsletter. Less
Something went horribly wrong with your application submission. Please try again later.

Frequently Asked Questions

Product FAQ

1. Will my app stop working or can my clients be affected if the Codavel Performance Service suffers a down-time?

No. Codavel Performance Service has built-in, at its core, a resilient fallback mechanism, where, if the Codavel SDK fails to connect to the Codavel Performance Service, for any reason, it will transfer the intended requests using regular HTTP/HTTPS to your desired endpoints. With this mechanism, the application or service will keep working as if nothing was out of normal and you will see no performance regressions.

2. Can I make my app/service stop using Codavel Performance Service without the need for releasing an update to my app?

Yes. Codavel Performance Service, via the Codavel SDK, allows remote control of when the Codavel Service is working. To stop an application from using the service, you can use one of the following strategies:

• Via the Codavel SDK, make use of the A/B testing percentage variable to 0, which would cause all traffic to go through regular HTTP. This is the recommended way of achieving the desired intent.

• Wrap the Codavel SDK start over a remotely configured variable, which would cause Codavel Service to not start, thus all traffic to go through regular HTTP.

3. Do I need to replace my current CDN deployment with Codavel Performance Service?

No. Codavel Performance Service can be deployed in front of current CDN deployment. However, with this setup, you are incurring a double traffic charge, for the Codavel Performance Service and for the CDN deployment. Moreover, some CDN providers may not allow you to expose their endpoints to other services. 

To leverage the full potential of Codavel Performance Service while maintaining our current CDN deployment, we recommend taking a look into our multi-CDN strategy section.


4. Can I deploy Codavel Performance Service in a Multi-CDN environment?

Yes. Codavel Performance Service can be easily seen as a regular CDN and all its route control can be made in the Codavel SDK. There, you can indicate another CDN as the single content origin, which will be used for all requests.

More complex strategies can be implemented. For example, you can very easily set a source for the content origin that Codavel Performance Service must use and set an alternative CDN as a fallback, in case Codavel Service fails.

On top of that, you can also specify which requests should be transferred by Codavel Performance Service, giving you even more control. For example, you can specify that only image and video requests shall be optimized by Codavel Performance Service, leaving all the remaining requests, as for example those related to login or payment, going through your existing method without modifications.



5. Can I specify which requests should be transferred using Codavel Performance Service?

Yes. By default, when Codavel Performance Service is enabled on the Codavel SDK, all requests are transferred via the Codavel Service. However, with Codavel SDK, you can specify which requests should be transferred via Codavel Performance Service. This mechanism is done in the Codavel SDK interceptor, where only requests that match a specific pattern are transferred via Codavel Service, with requests that do not match the pattern being transferred using your existing HTTP flow.


6. How does Codavel Performance Service work with HTTPS requests?

Codavel Performance Service integrates with your app by intercepting HTTP requests at the HTTP library via the Codavel SDK. The intercepted HTTPS (or HTTP) requests are then sent to the Codavel Performance Service cloud servers using an end-to-end encrypted Bolina connection. In the Codavel Performance Service cloud servers, if data is not cached, then the Codavel Performance Service will perform a request to the original URL, as if it was a regular client, using HTTPS (or HTTP if that is the case). Thus, HTTPS requests are always encrypted between all entities when they are passed through the wire.

7. Do I need to manage TLS certificates?

No. Even though Codavel SDK integrates into your app by attaching an interceptor to the HTTP libraries, it is not required to be the only interceptor enabled. In fact, you can make use of Codavel SDK helper methods to integrate the Codavel SDK interceptor as the last interceptor of the interceptor’s chain. This way, all your existing interceptors, that manage for example your sessions or cookies, will continue to work, while Codavel Performance Services is still capable of receiving and managing the transfer itself.

9. Is Codavel SDK compatible with external monitoring/debug tools such as Crashalitics and others?

Yes. When properly configured, Codavel SDK will not interfere with your existing monitoring and debugging tools. To achieve this, we recommend that you integrate the Codavel SDK interceptor as the last interceptor in the HTTP library interceptor chain, by using the provided helper methods.


10. How does Codavel Performance Service cache know when and when not to cache data?

Codavel Performance Service cache component relies on the HTTP cache headers, such as Cache-Control, Expires, and Access-Control-Max-Age headers. If no such headers are present, or if those headers indicate that the request should not be cached, then the cache component will not cache those requests. 


11. Given that Codavel Performance Service acts as an HTTP proxy, will my requests take longer?

No. Even though Codavel Performance Service acts as an HTTP proxy, the added latency that it introduces is negligible when compared to the benefit it brings by overcoming the issues found on the connection to the client. Moreover, by deploying a caching mechanism, depending on the service, most requests can be cached on the Codavel Performance Service cloud servers, meaning that there is a reduced need to fetch data from the content origin.


12. How does Codavel Performance Service deal with DRM or authentication?

If your DRM or authentication scheme is based on HTTP headers, then Codavel Performance Service will not have any impact on our service. However, if your DRM or authentication scheme consists of creating a unique object for each client, even if they request the same URL, then Codavel Performance Service will not be able to cache the object and will need to fetch data directly from your existing endpoint. Still, Codavel Performance Service will provide an increase to your network transfer speed, therefore improving your business KPIs, given that it will still improve upon the issues present in the wireless last mile.


13. What data does Codavel collect?
  • Request ID
  • UUID (randomly generated by our SDK)
  • Time
  • Network type (WiFi/mobile) (optional)
  • Network name (SSID and Carrier) (optional)
  • User-agent
  • Device Model (optional)
  • Device OS (Android/iOS)
  • OS Version
  • HTTP response status code
  • Timeout error reason
  • HTTP or HTTPS
  • HTTP request size
  • HTTP response size
  • HTTP method 
  • Content encoding
  • Content-type
  • Transfer encoding
  • Response time
  • Time to first byte
  • Waterfall - DNS time duration
  • Waterfall - connection establishment time
  • Waterfall - request headers time
  • Waterfall - request body time
  • Waterfall - response headers time
  • Waterfall - response body time
  • Fallback
  • HTTP URL
  • HTTP Headers
  • If fallback, fallback reason
  • If fallback, Codavel server domain, origin server domain, origin server address
  • Is ab testing
  • Interceptors version
  • Connection start, stop, duration
  • Handshake reply (error or not)
  • 0 RTT enabled
  • 0 RTT successful
  • Fallback to 1 RTT
  • 1 RTT successful
  • Is using certificates
  • Are certificates valid
  • If certificates invalid, reason
  • MTU
  • Is UDP blocked
  • Is TCP blocked
  • Is throttled
  • If is throttled, reason
  • RTT min
  • Avg RTT
  • Jitter
  • PLR
  • Out of order Core version
13. What data does Codavel collect?
  • Request ID
  • UUID (randomly generated by our SDK)
  • Time
  • Network type (WiFi/mobile) (optional)
  • Network name (SSID and Carrier) (optional)
  • User-agent
  • Device Model (optional)
  • Device OS (Android/iOS)
  • OS Version
  • HTTP response status code
  • Timeout error reason
  • HTTP or HTTPS
  • HTTP request size
  • HTTP response size
  • HTTP method 
  • Content encoding
  • Content-type
  • Transfer encoding
  • Response time
  • Time to first byte
  • Waterfall - DNS time duration
  • Waterfall - connection establishment time
  • Waterfall - request headers time
  • Waterfall - request body time
  • Waterfall - response headers time
  • Waterfall - response body time
  • Fallback
  • HTTP URL
  • HTTP Headers
  • If fallback, fallback reason
  • If fallback, Codavel server domain, origin server domain, origin server address
  • Is ab testing
  • Interceptors version
  • Connection start, stop, duration
  • Handshake reply (error or not)
  • 0 RTT enabled
  • 0 RTT successful
  • Fallback to 1 RTT
  • 1 RTT successful
  • Is using certificates
  • Are certificates valid
  • If certificates invalid, reason
  • MTU
  • Is UDP blocked
  • Is TCP blocked
  • Is throttled
  • If is throttled, reason
  • RTT min
  • Avg RTT
  • Jitter
  • PLR
  • Out of order Core version

Security FAQ

1. Is it safe to use Codavel Performance Service to transfer my customer’s data?

Yes. Codavel Performance Service uses a proprietary network protocol named Bolina to transfer data. This protocol includes end to end encryption, meaning every byte transferred between your app and the Servers are encrypted. Bolina ensures secure communication through two well known and tested open source libraries (OpenSSL for Server Authentication and Libsodium for Key Exchange Protocol and Data Encryption), through algorithms that are used as described in TLS 1.3. It is worth noting that cipher suites, signature algorithms and other parameters that are usually negotiated between client and server during TLS handshake, are pre-selected in Bolina Security Layer. From all the cipher suites available in TLS 1.3, Bolina Security Layer uses the most efficient, fastest and secure algorithms, ChaCha20 for encryption and Poly1303 for authentication.

2. Who can access the data transferred via Codavel Performance Service?

No one, literally no one, not even Codavel. The privacy of your users are Codavel’s top priority. Every byte transferred using Codavel Performance Service is encrypted, meaning no one has access to it. Bolina, our network protocol, uses authenticated encryption with ChaCha20 for encryption and Poly1303 for authentication.

Bolina uses an Authenticated Encryption with Associated Data (AEAD) algorithm ensuring that all messages are encrypted with the secret key agreed in the previous step and that forged messages are rejected. Using a shared secret of 256 bits, a nonce of 64 bits, and an additional data of 64 bits, Bolina uses stream cipher ChaCha20 for encryption and Poly1305 for message authentication, for all the communications end to end.

ChaCha20 is a high-speed cipher designed to provide 256-bit security. It is considerably faster than AES in software-only implementations (e.g., three times faster on platforms without specific AES hardware). On the other hand, Poly1305 is a high-speed message  authentication code, used to make sure that the transmitted messages have not been tampered. The combination of the ChaCha20 stream cipher with the Poly1305 authenticator (ChaCha20-Poly1305) was selected by Google to secure traffic between the Chrome browser on Android phones and Google’s websites, and is now included in the final version of  TLS 1.3, released on August 2018.

3. My servers are more exposed to attacks when using Bolina?

No. Servers are more protected with Codavel Performance Service due to the new protection layer provided by the service:

  • Only Codavel Performance Service servers access your servers
  • Codavel Performance Service has a dedicated intelligent shield that detects attacks and blocks potential attackers
  • Cached objects are served directly from the Codavel Performance Service

Following the recommended architecture, you should block all the requests to your servers except the ones from Codavel Performance Service. Doing that, only Codavel Performance Service servers have direct access to your servers, so risk of attack to your servers is reduced dramatically, with your servers becoming invisible to the world.

Notice, you can expose your servers to any other service, such as regular CDNs, which can be used in a fallback event, providing similar levels of exposure.


Dedicated intelligent shield

Codavel Performance Service offers an advanced, intelligent shield component that detects and blocks attackers by analysing their flow. This shield component applies firewall rules, identifies DDoS attacks and applies WAF rules to further identify an attacker. Moreover, the shield component continuously monitors Bolina packets to identify potential protocol attacks.

Once an attacker is detected, he is added to a suspicious list and future attack attempts are rejected applying rate limiting. Moreover, Codavel Performance Service scales to adapt to the current needs, therefore, it will scale to absorb a potential attack.

The only way to send traffic to your servers is being a legitimate end-user app, using Bolina correctly and not belonging to any Codavel’s block list.


Serving cached objects

When objects requested are cached, Codavel Performance Service is capable of serving them directly without performing calls to your servers, thus without the intervention of your servers.

4. Does Bolina follow TLS1.3 guidelines and how does Codavel Performance 0-RTT work?

Yes. Bolina protocol uses standard open-source cryptographic libraries, namely OpenSSL and Libsodium, which are used unmodified. Bolina security follows the TLS 1.3 guidelines for establishing secure connections, using cryptographic algorithms covered by the FIPS 140-2 recommendations.

Bolina provides two handshake modes, which are based on TLS 1.3:

  • A full 1-RTT handshake in which the client is able to send protected application data after one round trip time;
  • A 0-RTT handshake in which the client is able to send protected application data immediately, using information learned from a prior connection established with a full handshake.

In both modes, the server is authenticated, but the client remains anonymous.

1-RTT Handshake

In 1-RTT handshake mode, client starts by sending a ClientHello message to server, containing key shares. Server replies to the client with a ServerHello message, containing key shares and a certificate chain, signed with server’s RSA/ECDSA Private key. After this message exchange, client verifies server identity, ensuring that:

  • Certificates are not expired;
  • Chain of trust is valid and signed by a trusted certificate authority;
  • Certificates are valid for the domain;
  • Signature on ServerHello message matches server RSA/ECDSA Public Key.


Using their own X25519 Private Key and the other peer’s X25519 Public Key, both client and server compute a shared secret, aborting the negotiation if it is the all-zero value. From the shared secret, and from X25519 Public Keys, both peers derive a symmetric key to send and receive encrypted application data over the connection. In 1-RTT mode, client and server can start sending protected application data after 1-RTT and 1.5-RTT, respectively.


0-RTT Handshake

When a client is establishing a connection to a known server (i.e. a server to which the client has already connected in the past), it can establish a secure connection in a 0-RTT handshake. To achieve this, the client adds 0-RTT data (data that allows the server to map a symmetric key) to the ClientHello message and uses a shared secret, obtained in a previous handshake, to authenticate the server and to encrypt the application data, that is sent at the same time as the ClientHello message. The server can decrypt the received data using the symmetric key that is identified in the 0-RTT data, and encrypt messages to the client with the same key. Client and server also send to each other a new key share to use in a future 0-RTT handshake.


In Bolina, 0-RTT handshake ensures equivalent security guarantees to those achieved with 1-RTT handshake. Specifically:

  • For each new connection, a new ephemeral session key is generated through a new run of the Diffie-Hellman key exchange algorithm. This means that if a session key is compromised, it cannot be used to decrypt messages from prior or future sessions.
  • The guarantees against a replay attack on the 0-RTT handshake messages is provided by a unique value, which is encrypted and sent by the server in a prior connection, and which a client can use only once in a 0-RTT handshake message. Messages sent by a client that reuse this value will be ignored by the server.


5. I am currently using HTTP with SSL, how does it compare with Bolina from a security perspective?

With Bolina you get the same level of privacy and encryption as HTTP with SSL. Moreover, the Bolina handshake is optimized, pre selecting the cipher suites, signature algorithms and other parameters. This optimization enables the reduction of the number of messages transmitted between the mobile device and the Service and, by selecting the most efficient parameters for mobile, provides a significantly faster encryption and decryption maintaining the strong security.


6. Does Codavel Performance Service replace HTTP+TLS+SSL?

Codavel’s proprietary protocol – Bolina – does not replace HTTP. Bolina is integrated with HTTP, with no required changes to HTTP requests. Bolina can be seen as a transport tunnel that can be used to accelerate every type of data (irrespective of the protocol, being HTTP, FTP, DNS or other).