GoTLCP implements two Chinese national transport protocols over the same API shape: TLCP on TCP, DTLCP on UDP

Two protocol standards share the library, not the transport

GoTLCP implements the guomi, or Chinese commercial cryptography, transport layer as two separate standards over two different transports. TLCP follows GB/T 38636-2020, Information security technology Transport Layer Cryptography Protocol, extended under GM/T 0024-2023, the SSL VPN technical specification, to add SM9-based identity-based cryptography suites. It runs over TCP and is handed back as a net.Conn, which makes it the one to reach for with web services and API gateways. DTLCP follows GM/T 0128-2023, the datagram transport layer cryptography specification, and runs over UDP as a net.PacketConn, for the case where you need the cryptography but cannot depend on TCP's reliable delivery. The two are parallel packages, tlcp and dtlcp, with parallel Config, Dial and Listen surfaces, so choosing a transport is the first decision and everything after it mirrors.

The module path is gitee, and the Go floor is 1.25

Installation is a single command, and it does not go through a GitHub path:

go get -u gitee.com/Trisia/gotlcp

The go.mod in the repository agrees: the module is declared as gitee.com/Trisia/gotlcp and requires Go 1.25.0, plus two dependencies, github.com/emmansun/gmsm at v0.44.1 and golang.org/x/crypto at v0.54.0. That host detail has a practical consequence for anyone building this into a pipeline, since a build agent that can reach GitHub is not automatically able to reach gitee, and the README anticipates the problem by pointing at a gitee mirror if cloning or previewing the documentation is difficult. The README also states that the project keeps guaranteeing downward API compatibility, so upgrading the library is presented as safe. The Go requirement is the other constraint: 1.25 or above, which is a recent floor rather than a conservative one.

Servers need two certificates, a signing one and an encryption one

The single most visible difference from a TLS server configuration is the certificate slice. A TLCP server builds a Config whose Certificates field takes two entries, a signing certificate and an encryption certificate, both of type tlcp.Certificate:

config := &tlcp.Config{
	Certificates: []tlcp.Certificate{sigCert, encCert},
}
listen, err := tlcp.Listen("tcp", ":8443", config)

The DTLCP server quickstart does exactly the same with dtlcp.Certificate. That pairing is the reason there is a dedicated document on parsing and constructing signing and encryption certificates, which also covers the SM9 identity keys and public parameters needed for IBC setups. It is also why the example directories include a certkey directory: the certificates are not something you can reuse from a normal web deployment. On the client side there is a single Config with InsecureSkipVerify, which the quickstart sets to true to skip verification while reading from a local address.

Eight named cipher suites, four under SM2 and four under SM9

The suite list is given by name rather than left to negotiation, and it splits along the two algorithm families. The SM2 series has four: ECC_SM4_GCM_SM3, ECC_SM4_CBC_SM3, ECDHE_SM4_GCM_SM3 and ECDHE_SM4_CBC_SM3, the difference being elliptic curve versus ephemeral Diffie-Hellman and GCM versus CBC. The SM9 series has four more: IBC_SM4_GCM_SM3, IBC_SM4_CBC_SM3, IBSDH_SM4_GCM_SM3 and IBSDH_SM4_CBC_SM3, where IBC is identity-based and IBSDH adds the ephemeral Diffie-Hellman step to identity-based keys. SM9 support is the extension rather than the baseline, which is why there are two extra documents, an IBC quick start and an IBC configuration and usage guide, and why the guide covers a trust pool, mutual authentication, session resumption and a mapping of warnings to security conditions. The underlying SM algorithms come from emmansun/gmsm, credited in the acknowledgements for its CPU instruction set optimisations.

Handshake, resumption and both authentication directions are in scope

The stated scope of the implementation is the record layer protocol, the handshake protocol family and key computation, and the feature list that follows is short enough to quote as a checklist: full handshake, session resumption, transport protection, one-way identity authentication of the server, and two-way identity authentication. For most users the first and last of those are what matter, since one-way means the client checks the server and two-way means the server checks the client back, and TLCP is built on that dual-certificate arrangement. Resumption is the one people forget to ask about and the reason not to treat this as a thin wrapper. The DTLCP design document is where the internals are written down, covering the protocol stack architecture, the record layer, the handshake protocol, the Flight mechanism, the retransmission state machine and Cookie-based denial of service protection, all of which exist because datagrams arrive out of order and can be replayed.

A DTLCP connection needs a type assertion to send a datagram

The DTLCP quickstart shows why the transport difference leaks into your code. Listen on udp returns something you can Accept from, but the accepted value has to be asserted to dtlcp.Conn before you can use ReadFrom and WriteTo, which is how the server echoes a payload back to the address it came from. The client side is the mirror image, dialing udp with a dtlcp.Config and then calling WriteTo with conn.RemoteAddr() before reading with ReadFrom, which returns the byte count, the source address and an error together. Because there is no stream to delimit messages, the server quickstart runs each accepted connection in its own goroutine and uses a 1024 byte buffer per connection. The TLCP quickstart needs none of this: a net.Conn with Read and Write is all the echo server there uses.

Gin, Fiber and net/http are the three named web integrations

The library states compatibility with Gin, Fiber and the standard go http package, and there is a dedicated HTTPS configuration document covering the TLCP client and Gin and Fiber server configurations for building guomi HTTPS. The repository layout backs that up with a top-level https directory and an example/https directory alongside the others. The broader documentation set is unusually complete for a project of this size and is worth reading before writing code: an AboutTLCP page for the protocol, handshake flow and suite explanations, a certificates and keys page, separate client and server Config field references, the HTTPS configuration page, and the protocol adapter README. That last one is for the case where you need to serve TLCP and TLS from the same port, described as a TLCP and TLS adaptive listener.

Three releases in three months, and two licence files side by side

The activity record is dense and recent. Releases v1.6.1 on 2026-09-29, v1.6.0 on 2026-09-28 and v1.5.0 on 2026-07-13 sit alongside a last push dated 2026-09-30, and the repository reports 101 stars, 25 forks and 0 open issues. There is a releasenote.md at the top level, which is where you would look for what changed between two of those tags. Two licence files sit next to each other, LICENSE and MulanLICENSE.txt, while the licence field for the project says MIT, so which terms govern a given use is worth settling rather than assuming from that field. The project also points at a separate tool, tlcpchan, for anyone who wants a quick guomi HTTPS proxy rather than a library, and the acknowledgements note that the TLCP protocol code was trimmed from the crypto/tls module of Go 1.19.

Editorial conclusion

GoTLCP is worth reaching for when you have to speak guomi to a partner who will not negotiate TLS, and you would rather not write a handshake state machine. The API is small, roughly a Dial, a Listen and a Config per transport, and it covers the parts people forget: session resumption, mutual as well as server authentication, and the second certificate that TLCP requires. Three things to verify before you rely on it. The module lives at gitee.com/Trisia/gotlcp rather than a GitHub path, so your proxy has to be able to reach gitee. You need Go 1.25 or newer, which is a recent floor. And there is a disclaimer document the README asks every user to read first, alongside a Mulan licence file next to the MIT one, so check which terms apply to your use before shipping it.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes