Network

RESTful API 아키텍처 REST(Representational State Transfer)는 Web을 개발하는데 지침을 제공하고 그 구조를 설명하기 위해 만들어진 소프트웨어 아키텍처 스타일이다. Restful API의 핵심은 URL을 Endpoint로 바라보는 것이 아니라 하나의 자원으로 바라보는 것이고, 일관성을 가져서 예측 가능하게 되는 것이다. 아래는 Rest 아키텍처에서 가지는 특성이라고 한다. 1.1 Stateless 무상태성 클라이언트-서버 요청에서 클라이언트 정보가 저장되지 않고, 각 요청은 분리되어야 한다. 1.2 Client-Server 구조 클라이언트, 서버, 리소스로 구성되어 있으며 HTTP로 요청이 이루어진다. 1.3 데이터 캐싱 캐싱이 가능하도록 하여 클라이언트-서버간 상호작용을 최소화한다. 1.4 일관된 인터페이스 리소스 식별이 가능해야 하며, 클라이언트에 전송된 표현과 구분되어야한다. 그리고 수신하는 표현을 통해 리소스가 조작되어야 한다. 클라이언트는 자기 서술적 메시지에 정보를 어떻게 처리해야 할지 설명하는 정보가 충분히 포함되어야 한다.(Content-type, method, encoding 등) 1.5 레이어드 아키텍처 지원 서버는 계층 구조(보안, 로드밸런싱 등)로 구성하는 계층화된 시스템을 가질 수 있다. 1.6 코드 온 디맨드 요청을 받으면 서버에서 클라이언트로 실행 가능한 코드를 전송하여 클라이언트 기능을 확장할 수 있다. 2.메서드와 상태 정리 Restful API에서는 자원에 대한 행위를 HTTP 메서드를 통해 나타내어 서버에서 이 메서드에 따라 처리하고, Response로 상태 코드를 전달해 응답의 상태를 표현한다. 2.1 메서드 메서드 설명 주된 용도 멱등성 (Idempotent) 안전성 (Safe) 예시 URI GET 리소스를 조회 데이터 조회 ✅ 예 (같은 요청 여러 번 해도 결과 동일) ✅ 예 (서버 상태 변경 없음) /users/1 POST 리소스를 생성 데이터 추가 ❌ 아니오 ❌ 아니오 /users PUT 리소스를 전체 수정 데이터 전체 업데이트 ✅ 예 ❌ 아니오 /users/1 PATCH 리소스를 일부 수정 데이터 일부 업데이트 ❌ 일반적으로 아니오 (서버 구현에 따라 다름) ❌ 아니오 /users/1 DELETE 리소스를 삭제 데이터 삭제 ✅ 예 (이미 삭제된 경우에도 동일한 응답 가능) ❌ 아니오 /users/1 OPTIONS 지원하는 메서드 조회 CORS 사전 요청 등 ✅ 예 ✅ 예 /users HEAD 리소스의 헤더만 조회 (본문 없음) 메타데이터 확인 ✅ 예 ✅ 예 /users/1 2.2 상태 상태 상태 코드 의미 설명 사용 예시 성공 (2xx) 200 OK 요청 성공 GET, PUT, PATCH, DELETE 등에 사용 데이터 조회 성공 201 Created 생성됨 POST 요청으로 리소스 생성 시 사용 회원가입, 글 작성 등 204 No Content 내용 없음 성공했지만 응답 본문이 없을 때 DELETE, PUT 성공 후 응답 없음 리다이렉션 (3xx) 301 Moved Permanently 영구 이동 리소스가 영구적으로 이동 URL 변경 안내 302 Found 임시 이동 리소스가 임시로 다른 위치에 있음 로그인 후 리디렉션 304 Not Modified 변경 없음 캐시된 리소스를 그대로 사용 가능 조건부 GET (If-Modified-Since 등) 클라이언트 오류 (4xx) 400 Bad Request 잘못된 요청 유효하지 않은 파라미터 등 필드 누락, JSON 파싱 실패 401 Unauthorized 인증 필요 로그인 필요 또는 토큰 오류 JWT 없음/만료 403 Forbidden 접근 금지 권한이 없는 경우 관리자 전용 접근 404 Not Found 리소스 없음 존재하지 않는 URI 요청 잘못된 ID로 조회 시 409 Conflict 충돌 중복 리소스 생성 시 등 동일 ID 중복 생성 등 422 Unprocessable Entity 처리할 수 없음 형식은 맞지만 의미가 잘못됨 폼 검증 실패 등 서버 오류 (5xx) 500 Internal Server Error 내부 서버 오류 서버 내부 예외 발생 예상치 못한 에러 502 Bad Gateway 게이트웨이 오류 서버가 잘못된 응답 수신 프록시, 게이트웨이 문제 503 Service Unavailable 서비스 불가 서버 점검 중 또는 과부하 서버 다운, 유지보수 504 Gateway Timeout 게이트웨이 타임아웃 응답 지연 백엔드 응답 지연 시 리차드슨(Richardson)은 Rest API를 잘 적용하기 위해 4단계의 성숙도 모델을 정의했다.

HTTPS 란? 이전 포스팅에서 HTTP에 대해서 썼다. 하지만 대부분 보안때문에 HTTPS를 필수로 사용한다. 그래야 네트워크 경유지에서 패킷이 탈취당해도 HTTP 메시지가 암호화되어있어 내용을 알 수 없기 때문이다. 암호화 방식은 크게 2가지로 나뉜다. 대칭키 암호화와 비대칭키 암호화 방식이다. HTTPS를 암호화하는 방식은 대칭키와 비대칭키 암호화를 둘다 쓰는 방식이라고 볼 수 있다. 1.1 대칭키 암호화 대칭키 암호화는 암호화와 복호화에 같은 키를 사용한다. 그래서 구현이 간단하고 빠르지만, 키가 탈취당하면 키를 획득한 사람이 암호화와 복호화가 모두 가능해서 키 분배에 어려움이 있다. 대칭키 암호화에 가장 많이 쓰이는 알고리즘은 AES 알고리즘이다. 1.2 비대칭키 암호화 비대칭키 암호화는 공개키(Public key)로 암호화하고 복호화는 개인키(Private Key)로 한다. 그리고 그 반대 역시 가능하다. 개인키로 암호화하면 공개키로 복호화할 수 있으며 두 키는 쌍을 이룬다. 주로 서버에서만 복호화하고 클라이언트에서 암호화하기 때문에 공개키를 아무에게나 줘도된다. 왜냐하면 암호화한 데이터는 서버에서만 복호화할 수 있기 때문이다. 비대칭키 암호화 방식은 또 다른 방식으로도 응용된다. 만약 공개키가 검증되었다면 이를 통해서 암호화된 정보의 출처 검증이 가능하다. 만약 어떤 데이터를 A회사가 제공한 공개키로 복호화에 성공한다면 데이터의 출처가 A사임을 알 수 있다. 또한 복호화에 실패한다면 A사의 데이터가 아님을 알수도 있다. 이런 공개키가 어떤 회사의 공개키인지 검증해주는 기관을 CA(Certificate Authority)라고 한다. 비대칭키는 키분배는 쉽지만 구현이 더 복잡하고 연산도 느리다. 비대칭키 암호화 가장 많이 쓰이는 알고리즘은 RSA 알고리즘이다. HTTPS는 비대칭키 암호화를 통해서 클라이언트가 생성한 대칭키를 서버에서 받아서 클라이언트가 생성한 대칭키를 사용하여 데이터를 전달한다. 이를 요약하면 다음과 같은 과정을 겪는다. 클라이언트가 서버의 SSL 인증서를 받는다.(공개키를 포함) 클라이언트는 세션키(1회용 키, 대칭키)를 생성하고 "서버의 공개키로 생성한 세션키를 암호화"하여 서버에 전달한다. 서버와 클라이언트는 서로만 아는 세션키(대칭키)를 이용해 데이터를 교환한다. 공개키(비대칭 키)를 사용하여 세션키를 교환하는 방식 자체는 위험의 소지가 있다. 예를 들면 중간에 해커가 공개키를 위조하여 클라이언트에게 보내도 클라이언트는 구분할 수가 없다. 그래서 진짜로 생각하고 그대로 클라이언트만의 세션키를 해커에게 보내줄 수 있게 된다. 이를 해결하기 위한 방법이 SSL/TLS 인증서다. 기술적인 해결방법보다는, 사회적인 합의와 신뢰에의한 해결방법이다. 대한민국 여권이 한국에서 발행된 것임이 증명되면 대한민국 출신이라고 신뢰하듯이, 엄격하게 증명된 소수의 CA 기관에서 인증된 공개키면 해당 서버에서 온 것임을 증명하는 것이다. 3.1 인증서 생성 서버는 CA를 통해 인증서를 발급받는다. 아래는 그 과정이다. 서버는 서버만 알고있는 [서버-공개키]와 [사이트 정보]를 CA에 보내며 SSL 인증서 발급을 요청한다. CA는 서버의 을 함께 해쉬화 하여 [Hashed-인증서-정보]를 만든다. CA만 알고있는 [CA-비밀키]를 사용하여 [Hashed-인증서-정보]를 암호화하여 Signature(서명)를 만든 후, 둘을 합쳐서 인증서를 생성하여 서버에 전달한다. 서버는 통신시 CA에서 발급받은 인증서를 클라이언트에게 준다. 인증서의 Signature는 [CA-공개키]로 복호화되면 [Hashed-인증서-정보]가 된다. 3.2 인증서 확인 클라이언트는 브라우저에 신뢰가능한 CA들의 [CA-공개키] 목록을 가지고 있다. 그래서 이 목록의 [CA-공개키]로 인증서 Signature를 복호화시 증명이 되는지 여부를 통해 해커가 아닌 옳바른 도메인에서 온 데이터가 맞음을 증명할 수 있게 된다.(신뢰 기반) 만약 브라우저에 내장된 [CA-공개키] 목록에 없는 기관의 인증서라면 브라우저는 경고창을 띄어준다. 이 때는 직접 해당 기관의 공개키 등을 확인하여 직접 확인해보고, 신뢰할 수 있는 기관인지 여부도 판단하여 사용하면 된다. 그리고 아래는 확인 과정이다 클라이언트는 서버에 요청하여 인증서를 받아온다. 인증서의 을 명시된 알고리즘으로 해시화한다. 그러면 [Hashed-인증서-정보]가 나온다. 클라이언트는 인증서의 Signature를 브라우저에 내장된 [CA-공개키]로 복호화한다. 이 값은 [Hashed-인증서-정보]다. 위의 2번째와 3번째에서 구한 [Hashed-인증서-정보]가 같은 값을 갖는지 확인하여 해커에게서 온 인증서가 아닌 올바르게 전달받은 인증서임을 증명한다. 실제 키 인증서 확인하는 과정에서는 인증서가 폐기된 인증서인지 여부까지 CA에서 확인하는 과정이 있다. Client에서 CRL 혹은 COSP를 통해 확인한다. 방법 확인 주체 설명 CRL 클라이언트 CA가 주기적으로 발행하는 폐기 목록을 클라이언트가 다운로드해 확인 OCSP 클라이언트 클라이언트가 인증서의 상태를 CA에게 실시간으로 물어봄 OCSP Stapling 클라이언트 (확인), 서버 (전달) 서버가 CA에서 받아온 OCSP 응답을 클라이언트에게 같이 전달해 성능 향상 3.3 인증서 확인 후 인증서 확인 후 [클라이언트-세션 키]를 생성하고, 이 키를 [서버-공개키]로 복호화하여 서버에 전달한 뒤 [클라이언트-세션 키]로 암호화 하여 데이터를 주고 받는다.

HTTP(Hypertext Transfer Protocol) 최근 면접을 보면서 기초들을 많이 까먹었고 제대로 정리되어 있지 않다고 느꼈습니다. 그래서 기초부터 다시 처음 배우는 마음가짐으로 글을 작성합니다... ㅜㅜ HTTP는 리소스들을 가져올 수 있도록 해주는 프로토콜이다. 특히 웹에서 이루어지는 데이터 교환의 기초이며, 주로 Server-Client간의 통신 프로토콜이다. 보통 웹 브라우저(크롬, 사파리 등)가 Client이고 Tomcat, Nginx 같은 것들이 Server 역할을 한다. 웹 서버는 리소스를 관리하고 제공한다. 웹 서버의 정적 파일을 전달해줄 수도 있지만, 누가 언제 요청했는지에 따라 동적으로 데이터를 전달해줄 수 있다. 예를들면 로그인시에 유저별로 받아오는 닉네임 정보는 다를 것이다. 그리고 이 웹 클라이언트는 용도에 맞는 웹서버를 통해 이러한 데이터들을 전달받는다. 1.1 MIME(미디어 타입, Content-type) MIME(Multipurpose Internet Mail Extensions)는 각기 다른 메일 시스템 사이에서 메시지가 오갈 때 겪는 문제점을 해결하기 위해 설계되었습니다. 더 자세하게는 각 메일 시스템이 자기 방식대로 첨부파일을 인코딩 처리하기 때문에, 어떤 파일인지와 인코딩 방식을 지정하여 호환되도록 만들기 위함이였습니다. HTTP통신에서도 다양한 유형의 파일을 전달하기 때문에 전달할 데이터에 대해서 MIME 타입을 통해 확인가능 하도록 만들어야 했습니다. 그래서 HTTP에서는 Content-type(데이터 형식), Content-length(데이터 크기), Content-Encoding(압축 방식)이라는 헤더를 통해서 데이터의 형식과 압축 방식을 보내주고, 웹 클라이언트에서는 해당 정보를 활용하여 데이터를 알맞게 처리합니다. HTTP에서 이미지를 받으면 MIME는 다음과 형식으로 받아올 것입니다. HTTP/1.1 200 OK Content-Type: image/jpeg Content-Length: 245760 Content-Encoding: gzip Content-Type: {주타입}/{부타입}; charset={인코딩 방식,utf-8 등} Content-Length: 파일 크기 Content-Enccoding: {압축방식, gzip 등등 1.2 URI (uniform resource identifier, 통합 자원 식별자) 웹 서버 리소스는 각자 이름을 갖고 있고, 클라이언트는 해당 리소스를 지목할 수 있어야 한다. 그리고 이러한 서버 리소스의 이름을 URI라고 부른다. 이 URI는 정보 리소스를 고유하게 식별하고 위치를 지정할 수 있도록 도와준다. 예를들면 이 블로그 배경화면 동영상의 URI는 https://api.yooncarrot.com/static/home/background2.mp4이다.(S3서버 주소와 S3에서 해당 파일의 리소스 위치를 알면, S3서버 주소를 통해 접근할 수도 있다.) URI는 URL과 URN 2가지 종류가 있다. URL(uniform resource locator) 특정 서버의 한 리소스에 대한 구체적인 위치를 의미한다. 그리고 URL은 3 부분으로 이루어진다. 스킴(scheme): https://(보통 사용되는 프로토콜) 서버의 인터넷 주소(도메인) : api.yooncarrot.com 서버에서 리소스 위치: /static/home/background2.mp4 URN(uniform resource name) 리소스 위치에 영향없이 유일한 이름 역할을 한다. 리소스 위치를 옮기더라도 이 URN은 문제없이 작동해야하며, 프로토콜 상관없이 접근할 수 있다. (urn:네임스페이스:네임스페이스에서이름 으로 된다. urn:isbn:9780134092669) 보통 책, 논문 정보를 이런식으로 저장한다. 현재는 사실상 거의 쓰이지 않는다. HTTP 트랜잭션은 요청(client -> server)과 응답(server -> client)로 구성된다. 그리고 이 상호작용은 정형화된 HTTP 메시지로 이루어진다. 요청 GET /static/home/background2.mp4 HTTP/1.1 Host: api.yooncarrot.com 응답 HTTP/1.1 200 OK Content-type: video/mp4 Content-Length: 981314 요청 에는 HTTP 메서드 정보, 보낼 서버 주소, 경로가 포함되며 응답에는 프로토콜 버전, 응답 상태, MIME 정보 등이 포함된다. 그리고 웹페이지를 띄우기 위해서 보통 여러번의 HTTP 트랜잭션을 거친다.(HTML문서를 가져오고, JS 파일 가져오고, 이미지 가져오고...) 2.1 HTTP 메서드 클라이언트는 요청을 할 때 HTTP 메서드로 서버가 어떤 동작을 취해야 하는지 알려준다. 메서드 설명 GET 지정한 리소스를 클라이언트에게 보내라 PUT 클라이언트에서 서버로 보낸 데이터를 지정한 이름의 리소스로 지정하라 DELETE 지정한 리소스를 서버에서 삭제하라 POST 클라이언트 데이터를 서버 게이트웨이 애플리케이션에 전송하라 HEAD 지정한 리소스의 HTTP 헤드 부분만 클라이언트에게 보내라 OPTIONS 서버에서 어떤 메서드가 가능한지 클라이언트에게 알려주라 2.2 상태 코드 모든 HTTP 응답에는 상태 코드와 사유 구절(OK와 같은 문구)을 함께 보낸다. 사유 구절은 단순 참고용으로 상태는 HTTP Status Code를 통해 처리된다. 상태코드 설명 200 정상 302 리소스가 일시적으로 이동되었으니 redirect 해라 404 없는 리소스 HTTP 메시지는 binary형식이 아닌 일반 텍스트이기 때문에 읽고 쓰기가 쉽다. 그리고 이 HTTP 요청과 응답은 시작줄, 헤더, 바디와 구분을 위한 빈줄, 본문으로 이루어져 있다. 시작줄 요청이라면 무엇을 해야하는지 서버에게 전달하고, 응답이라면 무슨일이 있어났는지 클라이언트에게 전달한다. 헤더 헤더는 key value를 쌍점(:)으로 구분되어 전달되게 된다. 값을 추가한다면 1줄을 추가하면 된다. 본문 본문은 헤더의 빈줄 다음에 나온다. HTTP 메시지는 본문에 바이너리 데이터를 포함할 수 있다. HTTP 통신을 하기 위해서는 TCP 커넥션이 필요하다. 그리고 HTTP는 네트워크 개념에서 TCP 위의 계층이다 위와 같이 다양한 네트워크 모델이 있는데, 이중에서 최근 업데이트된 TCP/IP 5계층을 기준으로 HTTP가 전송되는 과정을 표로 정리하면 다음과 같다. 그리고 그 전송 과정을 그림으로 나타내면 아래와 같다. 자세히 설명하자면 컴퓨터 어플리케이션을 통해 데이터를 보낸다면 다음과 같은 순서의 과정을 겪을 것이다. 애플리케이션 데이터 생성 전송계층에서 TCP/UDP 헤더(포트) 추가 (세그먼트 생성) 네트워크 계층에서 IP 헤더 추가 (패킷 생성) 내부 네트워크면 ARP 테이블을 확인하여 목적지 IP의 MAC 주소 존재 여부 확인하고, 없으면 ARP를 통해 목적지 IP ARP 테이블 갱신. 외부 네트워크면 ARP 테이블의 기본 게이트웨이(다음 홉)의 MAC 주소 받아서 사용 ARP 테이블에서 다음 홉 MAC 주소를 이용하여 이더넷 헤더 추가(프레임 생성) 랜카드로 프레임 전달 랜카드는 다음 홉 MAC주소로 데이터 전달. 데이터 전달 중 목적지 주소 IP가 ARP 테이블에 존재하는 라우터가 존재하면 해당 ip에 최종적으로 전송. 하지만 클라이언트는 위 과정에서 서버 ip주소를 찾아야하는데 보통 도메인 주소를 입력한다. 그러면 어떻게 도메인 주소로 ip를 알아낼 수 있을까?? 예를 들면 yooncarrot.com의 443 포트로 https 통신을해야하는데 yooncarrot.com의 ip주소를 알아야 해당 서버에 접근할 수 있어야 한다. 이는 DNS를 통해 도메인 주소에 해당하는 ip주소를 받아오고 해당 ip주소로 https 통신을 했기 때문이다. HTTP는 0.9, 1.0, 1.1, 2.0, 3.0 까지 나오면서 계속 발전하고 있다. 현재는 3.0 까지 나온 상태이며 1.1과 2.0 버전이 가장 빈번하게 사용되고 있다. 5.1 HTTP/0.9 HTTP/0.9는 HTTP 프로토타입이다. HTML 파일만 전송할 수 있었고 GET 메서드만 존재했다. 5.2 HTTP/1.0 처음으로 가장 널리 쓰인 버전이다. 버전 번호, Header, Method, MIME가 추가되었고 웹페이지 Form으로 상호작용할 수 있게되었다. 그리고 급격하게 WWW이 팽창하면서 keep-alive 커넥션, 가상 호스팅 지원, 프락시 연결 지원 등 많은 기능이 추가되었다. keep-alive는 클라이언트와 서버간의 여러 요청과 응답을 하나의 tcp connection으로 처리할 수 있도록 만들었다. 그래서 매 요청마다 connection이 이루어지는 비용을 줄여 더 효율적으로 처리될 수 있도록 만들었다. 그리고 connection을 끊으려면 헤더에 Connection: close를 포함시켜 끊을 수 있도록 만들었다.(하나의 응답이 늦어지면 이후의 응답이 늦어지는 현상은 HOL blocking이라고 한다.) 5.3 HTTP/1.1 HTTP/1.1은 HTTP 설계의 구조적 결함 교정, 두드러진 성능 최적화, 잘못된 기능 제거에 집중되었고 더 복잡해진 웹 애플리케이션 배포를 지원한다. keep-alive 기능을 default로 변경하였고 파이프라이닝 기능이 추가되었다. 파이프라이닝은 하나의 연결에서 여러 요청을 순차적으로 보내고 순차적으로 받을 수 있도록 해주는 기능이다. 응답 순서가 보장되어야하기 때문에 느린 응답 하나가 전체 응답을 지연시키기도 하지만 파이프라이닝 구현이 어렵기도 하고 프록시 서버가 제대로 처리하지 못해서 문제가 많아 지금 사용되지 않는다. 5.4 HTTP/2.0 HTTP/2.0은 데이터를 header와 body를 frame이라는 데이터 단위로 만들어 text가 아닌 binary화 하여 steam화 하여 보낸다. 그리고 multiplexing(멀티플렉싱)이라는 기능과 Server Push기능이 추가되었다. HTTP/2.0은 요청마다 헤더를 1개나 2개의 header frame과 0개 이상의 data frame으로 나누어 1개의 stream으로 만들어 보낸다. multiplexing(멀티플렉싱)은 HOL(Head of Line) Blocking를 해결하고자 생긴 기능이다. frame 단위로 데이터를 보내면서 3개의 요청이 있을 경우 꼭 순서대로 Header를 보내지 않고 3번째 요청의 Header보다 2번째 요청의 Header frame을 보낼 수 있도록 만들었기 때문에 요청 순서에 따라 응답이 순서대로 처리되는 현상을 개선했다. 물론 Application Layer에서는 극복되었지만 TCP Connection에서 frame을 주고 받았기 때문에 TCP에서 발생하는 HOL Blocking을 해결할 순 없었다. 예를 들면 중간에 어떤 Header의 패킷 손실이 있었다면 해당 손실된 패킬이 올 때까지 기다리는 동안 그 뒤에 받아야할 데이터들은 여전히 기다려야한다. Application Layer에서의 HOL Blocking은 해결했지만 Transport Layer에서의 HOL은 해결하지 못했다. Server push는 클라이언트가 HTTP 요청하기 전에 서버가 먼저 클라이언트에 리소스를 보내는 것이다. 하지만 클라이언트는 서버가 보낸 리소스를 알지 못하고 다시 요청하기 때문에 이 기능은 제거되었다. 5.5 HTTP/3.0 HTTP/3.0에서는 Transport Layer에서 HOL Blocking 문제를 해결했다. 이를 해결하기 위해서 TCP에 의존하지 않고 UDP에 기반한 QUIC 프로토콜을 사용했다. 그래서 TCP에 기반한 Stream들이 UDP에 기반한 QUIC 프로토콜을 사용하여 각 스트림이 독립적이게 되었다. Connection을 맺는데 0초의 시간이 걸리게 되었다. QUIC 프로토콜을 사용하게 되면서 각 요청 Stream이 독립적으로 작동할 수 있게 되었다. 쉽게 예를 들면 모든 요청들을 1개의 파이프를 통해서만 보내야 했다면, QUIC 프로토콜을 사용하면서 각 요청의 개수만큼의 파이프를 사용하여 요청을 보낼 수 있게된 것이다. 즉 패킷을 1개의 파이프가 아니라 여러 파이프로 보낼 수 있게 되었다. QUIC 프로토콜은 TCP와 TLS 위에서 작동하지 않고 QUIC에서 통합 처리하기 때문에 지연이 매우 적다. QUIC은 UDP기반으로 동작하며 TLS 1.3이 내장되어 한 번 연결된 서버에 대해서는 재연결시 0-RTT(0 Round Trip Time)로 데이터를 바로 보낼 수 있다. 즉 핸드셰이크 없이 바로 데이터를 보낼 수 있어서 0-RTT로 데이터를 바로 보낼 수 있는 것이다.