ping, curl, telnet, 인증서, Authorization secretKey

ping은 뭐고 curl은 뭐고 telnet은 뭘까

일단 공통점이 있다. 네트워크 통신이 가능한지 확인하는 도구라는 것.

그러나 작동방식이 다른데...

ping
- ICMP 프로토콜을 사용한다 (TCP, HTTP가 아님)
- 회수율을 측정한다.
- 언제 사용할까?
  - 인터넷 연결 자체가 되는지 확인할 때
  - DNS가 잘 동작하는지 확인할 때
  - 서버가 살아있는지 확인할 때
- 한계점
  - ICMP는 방화벽에서 차단될 수 있다.
  - 포트 상태는 알 수가 없다 몰?루? (443포트가 죽어있어도 ping은 성공할 수 있음)

핑은 아이피가 아니라 도메인 주소로도 전송할 수 있다.

ping google.com

이 명령을 입력할 경우 컴퓨터는 먼저 DNS를 찾아본다. google.com을 8.8.8.8(google의 아이피 주소)로 치환하고, 이 주소로 ICMP ping 요청을 전송한다.

ICMP란 무엇인가...

ICMP (Internet Control Message Protocol)
네트워크에서 호스트나 라우터 간 상태를 알리는 신호를 주고받는 프로토콜

데이터 전송용 프로토콜이 아님 → 실제 웹, 파일, 메일 전송에는 사용하지 않음

1. 컴퓨터가 ICMP Echo Request 패킷 전송
2. 서버가 ICMP Echo Reply 응답
3. 왕복 시간(RTT) 측정 → 서버 살아있음 확인

curl
- 웹서버와 통신하기 위한 커맨드라인 도구(CLI)
- 프로토콜을 지원한다 (HTTP, HTTPS, FTP ...)
- 서버에 요청을 보내고 응답을 받을 수 있다.
  응답 상태 코드, 헤더, 바디 모두 확인 가능.
- 언제 사용할까?
  - 웹 서비스가 정상적인지 확인할 때
- 한계점
  - 기본적으로 HTTP/HTTPS만 테스트한다 (TCP 테스트에는 초큼 부적합)

curl https://example.com

telnet
- 보통은 tcp 포트에 연결되는지 확인하는 용도로 쓴다
  연결이 되면 tcp 접속이 가능하다는 것, 안 되면 포트가 닫혀있거나 방화벽이 막혀있거나...
- 언제 사용할까?
  - 특정 포트가 열려있는지 확인할 때
  - 실제 서비스 동작 여부는 알 수 없음 (프로토콜이 없거던~)

telnet example.com 443

* tcp 포트는 무엇인가?

컴퓨터는 여러 프로그램을 동시에 사용할 수 있지.
그런데 동시에 실행된 프로그램들에서 동시에 네트워크를 사용하려고 하면 어떻게 될까?
만약 포트가 없다면, A 컴퓨터에서 보낸 요청에 대한 응답을 B 컴퓨터가 받게 될 수도 있다.

운영체제는 각 프로그램을 포트 번호로 구분한다.

- 80번 포트 → 웹 서버(HTTP)
- 443번 포트 → 웹 서버(HTTPS)
- 3306번 포트 → MySQL
- 6379번 포트 → Redis
- 22번 포트 → SSH

tcp 포트 범위는 0에서부터 65535까지다.

- 0 ~ 1023 : 이미 예약된 포트
- 1024 ~ 49151 : 등록 가능한 포트
49152 ~ 65535 : 임시 포트 (클라이언트가 랜덤으로 사용한다)

telnet 켜는 방법 (telnet은 내부 또는 외부 명령, 실행할 수 있는 프로그램, 또는 배치 파일이 아닙니다...)

제어판(Control Panel) 열기
프로그램 → 프로그램 및 기능
왼쪽에서 Windows 기능 켜기/끄기 클릭
목록에서 Telnet Client 체크
확인 → 설치 진행

연결해봅시다.

curl을 사용하여 tcp 연결만 테스트하기 (https 요청 없이)

curl -v telnet://example.com:443

-v는 연결과정(verbose)를 출력한다

telnet:// 은 raw TCP로 붙어봄을 의미한다.

성공하면 Connected to example.com이 뜬다.

curl을 사용하여 443포트에 HTTPS 요청 보내기

curl -v https://example.com:443

telnet을 사용하여 포트 연결 확인하기

telnet example.com 443

성공하면 빈 화면에 커서만 깜빡 거릴 것.

연결이 실패하면 Connection refused가 뜬다.

curl, Connetcion was reset?

// curl 응답 메세지 분석

Host example.com:443 was resolved. // DNS는 성공했음, 도메인을 IP로 무사히 변환함
...
closing connection #0
curl: (35) Recv failure: Connection was reset // 연결 자체는 완료됨. 그러나 TCP 3-way handshake까지만 성공함. 즉... 포트는 열려있고 연결까진 성공했다. 하지만 통신을 하려고하자 서버가 끊었다.

Connetcion was reset?

서버 또는 중간 네트워크 장비가 RST 패킷을 보내며 연결을 강제로 종료했다는 것.

1. DNS 조회 성공

2. TCP 3-way handshacke 성공 (연결됨)

3. SSL/TLS handshake 시작 또는 HTTP 요청 전송

4. 서버가 RST 패킷을 보내며 연결 끊음 --->>> Connection was reset

telnet은 되는데 ping은 안 될 수가 있는가?

당연.

서버가 ICMP는 막고 TCP는 허용할 수 있기 때문...

telnet은 되는데 curl은 안 될 수가 있는가?

그렇다...

telnet은 프로토콜 검증이나 요청이 온 내용은 신경쓰지 않는다.

curl은 TLS handshake 실패, 인증헤더없어서거부, 잘못된URL 등을 검수하기 때문에 이 때 에러가 발생할 수 있다.

TLS handshake가 뭔데...

1️⃣ Client Hello (클라이언트 인사)

클라이언트(curl, 브라우저 등)가 서버에 연결 시도
서버에게 지원 가능한 TLS 버전, 암호화 방식(cipher suite), 랜덤 값 전달
목적: 서버가 어떤 방식으로 통신할지 정하도록 안내

2️⃣ Server Hello (서버 응답)

서버가 Client Hello를 받고 응답
선택한 TLS 버전, cipher suite, 서버 랜덤 값 전달
서버 인증서(Certificate)도 함께 전송
인증서에는 서버 공개키와 도메인 정보가 들어있음

3️⃣ 서버 인증 검증

클라이언트는 서버 인증서를 확인
- 신뢰할 수 있는 CA인지
- 도메인 이름과 일치하는지
- 만료되지 않았는지
검증 실패 시 handshake 중단 → 연결 실패

4️⃣ 키 교환(Key Exchange)

클라이언트와 서버가 **세션 키(Session Key)**를 안전하게 교환
세션 키 = 대칭키 암호화용 키
방법:
- RSA, Diffie-Hellman 등
이 단계 이후부터 실제 데이터는 암호화됨

5️⃣ Change Cipher Spec

클라이언트와 서버가 “이제부터 암호화해서 통신할 거야”를 서로 알림
이후부터 모든 패킷은 세션 키로 암호화됨

6️⃣ Finished (최종 확인)

양쪽이 “Handshake 성공, 암호화 통신 준비 완료” 메시지 교환
이제 HTTPS 요청/응답 시작 가능

Client: 안녕! 나 TLS1.2, AES256 써도 돼
Server: 좋아, TLS1.2, AES256 선택, 인증서 여기
Client: 인증서 확인 완료, 세션 키 만들었어
Server: 나도 세션 키 만들었어
Client & Server: 이제 암호화된 통신 시작!

SSL/TLS 인증서과 Authorization 시크릿 키

항목	목적	적용 위치	예시
Authorization 키 (Bearer token)	API 접근 권한 검증	HTTP 헤더	Authorization: Bearer <시크릿 키>
SSL/TLS 인증서	서버와 클라이언트 간 안전한 암호화 통신 보장	TLS handshake 단계	서버 공개키, 도메인, CA 서명 포함

HTTPS 통신 + API 시크릿키 사용 순서

TCP 연결 수립
- 클라이언트 → 서버 TCP 3-way handshake
- 포트: HTTPS 기본 443
- 예: telnet api-io.naver.com 443 성공 여부 확인 가능
TLS/SSL Handshake (HTTPS)
- 클라이언트가 서버에게 TLS Client Hello 전송
- 서버가 Server Hello + 인증서(Certificate) 전송
- 클라이언트가 인증서 확인:
  - 신뢰할 수 있는 CA 서명인지
  - 도메인 이름 일치 여부
  - 만료 여부
- 키 교환 및 세션키 생성 → 암호화 통신 준비
- handshake 실패 시 → schannel: failed to receive handshake, Connection reset 등
HTTPS 세션 시작
- TLS handshake가 성공하면 암호화된 채널 생성
- 이후 HTTP 요청/응답은 모두 암호화됨
HTTP 요청 준비
- curl 등 클라이언트가 요청 보낼 준비
- URL, 경로, 메소드(GET/POST) 결정
- 필요한 헤더 설정:
  - Authorization: Bearer <시크릿 키>
  - Content-Type: application/json 등
시크릿 키(Bearer token) 전송 및 인증
- HTTP 요청 헤더에 Authorization 포함
- 서버가 토큰 유효성 검사:
  - 만료 여부
  - 해당 API 접근 권한 확인
- 실패 시 → HTTP 401/403 응답
서버 응답 반환
- 인증 성공 → 요청 처리 후 JSON, XML 등 데이터 반환
- 인증 실패 → HTTP 오류 코드 반환
- 모든 응답은 TLS 세션을 통해 암호화되어 전달됨

1. TCP 연결
   Client ↔ Server (포트 443 연결)
2. TLS handshake
   Client Hello → Server Hello + Certificate → 세션키 생성
3. HTTPS 세션 시작
   암호화된 통신 채널 완성
4. HTTP 요청 전송
   GET /review
5. 시크릿 키 인증
   Authorization: Bearer <token>
6. 서버 응답
   JSON 데이터 반환

TLS/SSL 인증서: 통신 암호화, 서버 신뢰 확인 → TCP 연결 후 바로 수행
시크릿 키(Bearer token): API 접근 권한 확인 → TLS 세션 완성 후 HTTP 요청 레벨에서 사용
실패 시점 구분:
- handshake 실패 → curl schannel / Recv failure
- 인증 실패 → curl HTTP 401/403

저작자표시 비영리 변경금지 (새창열림)