A C library for asynchronous DNS requests (grpc依赖)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

97 lines
3.0 KiB

# Copyright (C) The c-ares project and its contributors
# SPDX-License-Identifier: MIT
name: Alpine (latest)
on:
push:
pull_request:
concurrency:
group: ${{ github.ref }}-alpine-latest
cancel-in-progress: true
env:
TEST_FILTER: "--gtest_filter=-*LiveSearchTXT*:*LiveSearchANY*"
CMAKE_FLAGS: "-DCMAKE_BUILD_TYPE=DEBUG -DCARES_STATIC=ON -DCARES_STATIC_PIC=ON -G Ninja"
MAKE: make
jobs:
build:
runs-on: ubuntu-latest
container:
image: alpine:latest
# Needed for TCP FastOpen
options: --privileged
name: "Alpine (latest)"
steps:
- name: Install packages
run: |
apk add bash cmake samurai gtest-dev autoconf autoconf-archive automake libtool pkgconf make clang17 clang17-analyzer compiler-rt lldb gcc g++ valgrind gdb sudo
- name: Checkout c-ares
uses: actions/checkout@v4
Implement TCP FastOpen (TFO) RFC7413 (#840) TCP Fast Open (TFO) allows TCP connection establishment in 0-RTT when a client and server have previously communicated. The SYN packet will also contain the initial data packet from the client to the server. This means there should be virtually no slowdown over UDP when both sides support TCP FastOpen, which is unfortunately not always the case. For instance, `1.1.1.1` appears to support TFO, however `8.8.8.8` does not. This implementation supports Linux, Android, FreeBSD, MacOS, and iOS. While Windows does have support for TCP FastOpen it does so via completion APIs only, and that can't be used with polling APIs like used by every other OS. We could implement it in the future if desired for those using `ARES_OPT_EVENT_THREAD`, but it would probably require adopting IOCP completely on Windows. Sysctls are required to be set appropriately: - Linux: `net.ipv4.tcp_fastopen`: - `1` = client only (typically default) - `2` = server only - `3` = client and server - MacOS: `net.inet.tcp.fastopen` - `1` = client only - `2` = server only - `3` = client and server (typically default) - FreeBSD: `net.inet.tcp.fastopen.server_enable` (boolean) and `net.inet.tcp.fastopen.client_enable` (boolean) This feature is always-on, when running on an OS with the capability enabled. Though some middleboxes have impacted end-to-end TFO and caused connectivity errors, all modern OSs perform automatic blackholing of IPs that have issues with TFO. It is not expected this to cause any issues in the modern day implementations. This will also help with improving latency for future DoT and DoH implementations. Authored-By: Brad House (@bradh352)
4 months ago
- name: "Make sure TCP FastOpen is enabled"
run: |
sudo sysctl -w net.ipv4.tcp_fastopen=3
- name: "CMake: build and test c-ares"
env:
BUILD_TYPE: CMAKE
CMAKE_TEST_FLAGS: "-DCARES_BUILD_CONTAINER_TESTS=ON"
TEST_DEBUGGER: gdb
run: |
./ci/build.sh
./ci/test.sh
- name: "Autotools: build and test c-ares"
env:
BUILD_TYPE: autotools
TEST_DEBUGGER: gdb
run: |
./ci/build.sh
./ci/test.sh
- name: "CMake: UBSAN: build and test c-ares"
env:
BUILD_TYPE: "ubsan"
CC: "clang"
CXX: "clang++"
CMAKE_TEST_FLAGS: "-DCARES_BUILD_CONTAINER_TESTS=ON"
CFLAGS: "-fsanitize=undefined -fno-sanitize-recover"
CXXFLAGS: "-fsanitize=undefined -fno-sanitize-recover"
LDFLAGS: "-fsanitize=undefined"
TEST_DEBUGGER: "none"
run: |
./ci/build.sh
./ci/test.sh
- name: "CMake: ASAN: build and test c-ares"
env:
BUILD_TYPE: "asan"
CC: "clang"
CXX: "clang++"
CMAKE_TEST_FLAGS: "-DCARES_BUILD_CONTAINER_TESTS=ON"
CFLAGS: "-fsanitize=address"
CXXFLAGS: "-fsanitize=address"
LDFLAGS: "-fsanitize=address"
TEST_DEBUGGER: "none"
run: |
./ci/build.sh
./ci/test.sh
Implement TCP FastOpen (TFO) RFC7413 (#840) TCP Fast Open (TFO) allows TCP connection establishment in 0-RTT when a client and server have previously communicated. The SYN packet will also contain the initial data packet from the client to the server. This means there should be virtually no slowdown over UDP when both sides support TCP FastOpen, which is unfortunately not always the case. For instance, `1.1.1.1` appears to support TFO, however `8.8.8.8` does not. This implementation supports Linux, Android, FreeBSD, MacOS, and iOS. While Windows does have support for TCP FastOpen it does so via completion APIs only, and that can't be used with polling APIs like used by every other OS. We could implement it in the future if desired for those using `ARES_OPT_EVENT_THREAD`, but it would probably require adopting IOCP completely on Windows. Sysctls are required to be set appropriately: - Linux: `net.ipv4.tcp_fastopen`: - `1` = client only (typically default) - `2` = server only - `3` = client and server - MacOS: `net.inet.tcp.fastopen` - `1` = client only - `2` = server only - `3` = client and server (typically default) - FreeBSD: `net.inet.tcp.fastopen.server_enable` (boolean) and `net.inet.tcp.fastopen.client_enable` (boolean) This feature is always-on, when running on an OS with the capability enabled. Though some middleboxes have impacted end-to-end TFO and caused connectivity errors, all modern OSs perform automatic blackholing of IPs that have issues with TFO. It is not expected this to cause any issues in the modern day implementations. This will also help with improving latency for future DoT and DoH implementations. Authored-By: Brad House (@bradh352)
4 months ago
- name: "CMake: Static Analyzer: build c-ares"
env:
BUILD_TYPE: "analyze"
CC: "clang"
CXX: "clang++"
Implement TCP FastOpen (TFO) RFC7413 (#840) TCP Fast Open (TFO) allows TCP connection establishment in 0-RTT when a client and server have previously communicated. The SYN packet will also contain the initial data packet from the client to the server. This means there should be virtually no slowdown over UDP when both sides support TCP FastOpen, which is unfortunately not always the case. For instance, `1.1.1.1` appears to support TFO, however `8.8.8.8` does not. This implementation supports Linux, Android, FreeBSD, MacOS, and iOS. While Windows does have support for TCP FastOpen it does so via completion APIs only, and that can't be used with polling APIs like used by every other OS. We could implement it in the future if desired for those using `ARES_OPT_EVENT_THREAD`, but it would probably require adopting IOCP completely on Windows. Sysctls are required to be set appropriately: - Linux: `net.ipv4.tcp_fastopen`: - `1` = client only (typically default) - `2` = server only - `3` = client and server - MacOS: `net.inet.tcp.fastopen` - `1` = client only - `2` = server only - `3` = client and server (typically default) - FreeBSD: `net.inet.tcp.fastopen.server_enable` (boolean) and `net.inet.tcp.fastopen.client_enable` (boolean) This feature is always-on, when running on an OS with the capability enabled. Though some middleboxes have impacted end-to-end TFO and caused connectivity errors, all modern OSs perform automatic blackholing of IPs that have issues with TFO. It is not expected this to cause any issues in the modern day implementations. This will also help with improving latency for future DoT and DoH implementations. Authored-By: Brad House (@bradh352)
4 months ago
SCAN_WRAP: "scan-build -v --status-bugs"
CMAKE_TEST_FLAGS: "-DCARES_BUILD_TESTS=OFF"
TEST_DEBUGGER: "lldb"
run: |
./ci/build.sh
./ci/test.sh
- name: "Valgrind: build and test c-ares (no TCP FastOpen)"
env:
BUILD_TYPE: "valgrind"
TEST_WRAP: "valgrind --leak-check=full"
TEST_FILTER: "--gtest_filter=-*Container*:*LiveSearchANY*:*LiveSearchTXT*"
CMAKE_TEST_FLAGS: "-DCARES_BUILD_TESTS=ON"
TEST_DEBUGGER: none
run: |
Implement TCP FastOpen (TFO) RFC7413 (#840) TCP Fast Open (TFO) allows TCP connection establishment in 0-RTT when a client and server have previously communicated. The SYN packet will also contain the initial data packet from the client to the server. This means there should be virtually no slowdown over UDP when both sides support TCP FastOpen, which is unfortunately not always the case. For instance, `1.1.1.1` appears to support TFO, however `8.8.8.8` does not. This implementation supports Linux, Android, FreeBSD, MacOS, and iOS. While Windows does have support for TCP FastOpen it does so via completion APIs only, and that can't be used with polling APIs like used by every other OS. We could implement it in the future if desired for those using `ARES_OPT_EVENT_THREAD`, but it would probably require adopting IOCP completely on Windows. Sysctls are required to be set appropriately: - Linux: `net.ipv4.tcp_fastopen`: - `1` = client only (typically default) - `2` = server only - `3` = client and server - MacOS: `net.inet.tcp.fastopen` - `1` = client only - `2` = server only - `3` = client and server (typically default) - FreeBSD: `net.inet.tcp.fastopen.server_enable` (boolean) and `net.inet.tcp.fastopen.client_enable` (boolean) This feature is always-on, when running on an OS with the capability enabled. Though some middleboxes have impacted end-to-end TFO and caused connectivity errors, all modern OSs perform automatic blackholing of IPs that have issues with TFO. It is not expected this to cause any issues in the modern day implementations. This will also help with improving latency for future DoT and DoH implementations. Authored-By: Brad House (@bradh352)
4 months ago
sudo sysctl -w net.ipv4.tcp_fastopen=0
./ci/build.sh
./ci/test.sh