프로토콜
데이터의 교환 방식을 정의하는 규칙 체계
표준화된 프로토콜은 컴퓨터가 사용할 수 있는 공통 언어와 같다
예를들어 인터넷은 TCP/IP ,WWW(월드 와이드 웹)은 HTTP, 이메일은 SMTP
의 프로토콜을 사용해 통신한다
포트 (PORT)
논리적인 접속장소로 네트워크에서 통신중에 특정 프로로그램의 서버로 접속할 수 있게 알려준다
일반적으로 알려진 포트들은 특정 프로토콜에 예약이 되어지만 기타 포트들은
HTTP는 포트80 HTTPS는 포트443 을 사용한다
Port는 해당 컴퓨터 안에서 특정 프로그램을 찾기 위한 주소라고 볼 수 있다
예를 들자면 'OO시 OO구 OO동'은 IP주소 , 'XX길 XXXX아파트 XX동 XX호'같은 상세주소는 PORT 라고 볼 수 있다
| Well-known ports (잘 알려진 포트) | 0~1023 | 시스템에서 사용하는 포트로 표준 서비스, 프로토콜에 할당됨 |
| Registered ports (등록된 포트) | 1024~49151 | 특정 프로토콜, 어플리케이션에서 사용하는 포트로 사용자가 등록하는 어플리케이션에 할당됨 일반적인 서비스, 어플리케이션에 사용됨 |
| Dynamic or private ports (동적 또는 개인 포트) | 49152~65535 | 어플리케이션에서 임시로 사용하는포트 클라이언트<->서버 연결시 동적으로 선택됨 |
| 번호 | 프로토콜 | 설명 |
| 80 | HTTP | 웹 페이즈 전송 |
| 443 | HTTPS | 암호화된 웹 페이지 전송 |
| 21 | FTP | 파일 전송 |
| 22 | SSH | 원격 서버에 안전하게 접속 |
| 23 | Telnet | 원격 호스트에 접속 |
| 25 | SMTP | 이메일을 보내기 |
| 53 | DNS | 도메인을 IP로 혹은 반대로 변환 |
| 110 | POP3 | 이메일을 수신 |
| 143 | IMAP | 이메일을 수신하고 관리 |
| 465 | SMTPS | SMTP의 보안버전 |
※잘 알려진 포트의 예시※
HTTP
Hypertext Transfer Protocol 의 약자로
네트워크 통신을 작동하게 하는 가장 기초적인 프로토콜이다
80번 포트(혹은 8080포트)를 사용한다
"웹 페이지의 통신을 위한 언어"
http의 작동 방식
1. 클라이언트가 서버에 접속한다
2. 접속한 서버에 원하는 데이터를 요청(Request)한다
3. 서버가 요청한 데이터를 클라이언트에게 응답(Response)한다
4. 서버와 클라이언트의 연결을 끊는다
의 순서로 작동한다
- 요청(Request)
클라이언트가 서버에게 보내는 메시지 (▼챗GPT를 사용해 만든 HTTP 요청 예시)
POST /submit-form HTTP/1.1
Host: example.com
Content-Type: application/json
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36
{
"username": "example_user",
"password": "example_password"
}
HTTP Method : 리퀘스트가 서버에게 어떤 동작을 요청하는지를 나타냅니다. 주요 HTTP 메소드에는 GET, POST, PUT, DELETE, 등이 있습니다. (위의 'POST' 에 해당)
URI : 리퀘스트의 대상이 되는 리소스를 식별합니다. 주소창에 입력되는 URL이나 URI가 여기에 해당됩니다. (위의 '/submit-form'에 해당)
HTTP Version : 사용되는 HTTP 프로토콜의 버전을 명시합니다. 예를 들어, "HTTP/1.1"이나 "HTTP/2" 등이 있습니다. (위의 'HTTP/1.1' 에 해당)
헤더 (Headers) : 리퀘스트에 대한 여러 정보들을 포함합니다. 예를 들어, 클라이언트의 정보, 요청의 유형, 리소스에 대한 정보 등이 포함될 수 있습니다. (위의 'Host', 'Content-Type', 'User-Agent' 에 해당)
메시지 바디 (Message Body) : 필요에 따라 리퀘스트에 데이터가 포함될 수 있습니다. 이는 주로 POST 메소드와 함께 사 용되며, 서버로 전송할 데이터를 담습니다. (JSON 형식의 데이터가 포함된다)
| GET | POST | PUT | DELETE | HEAD | OPTIONS | TRACE |
| 데이터 요청 | 데이터 넣기 | 데이터 업데이트 |
데이터 삭제 | 헤더 정보만 요청 |
지원하는 메서드 종류를 요청 | 클라이언트의 요청 반환 |
※ HTTP의 요청 메소드 ※
- 응답(Response)
서버가 클라이언트에게 보내는 메시지로 밑의 4가지로 구성되어 있다
1. 상태코드 (Status Code): 요청을 잘 처리했는지, 혹은 어떤 문제가 발생하였는지를 나타내는 세 자리 숫자
2. 상태 메시지 (Status Message): 상태코드와 같이 제공되는 간단한 설명
| 200 OK | 요청이 성공적으로 처리되었음을 나타냅니다. 이는 주로 GET 요청에 대한 성공적인 응답을 나타냅니다. |
| 404 Not Found | 요청한 리소스가 서버에 없음을 나타냅니다. 클라이언트가 요청한 URL이나 리소스를 찾을 수 없을 때 반환됩니다. |
| 500 Internal Server Error | 서버에서 요청을 처리하는 동안 내부적으로 오류가 발생했음을 나타냅니다. 이는 서버 측의 문제로 인해 요청이 처리되지 못했을 때 반환됩니다. |
| 401 Unauthorized | 요청한 리소스에 대한 인증이 필요함을 나타냅니다. 클라이언트가 인증되지 않았거나 잘못된 자격 증명을 제공한 경우 반환됩니다. |
| 403 Forbidden | 요청한 리소스에 접근할 권한이 없음을 나타냅니다. 서버가 요청을 거부했지만, 그 이유를 명시적으로 알리지 않는 경우에 반환됩니다. |
| 301 Moved Permanently | 요청한 리소스가 새로운 위치로 영구적으로 이동되었음을 나타냅니다. 클라이언트는 이후에 새로운 위치로 요청을 보내야 합니다. |
| 302 Found (or Temporary Redirect) | 요청한 리소스가 일시적으로 다른 위치에 있음을 나타냅니다. 클라이언트는 임시적으로 새로운 위치로 리디렉션됩니다. |
▲몇가지 상태코드와 상태메시지의 예시(좌 : 상태코드 , 우 : 상태메시지)
3. 헤더 (Headers): 응답에 대한 추가 정보를 포함하며 이 정보로 클라이언트 서버간 통신을 조정한다
요청이나 응답의 첫 번째 줄에 위치하며, 이후에 옵션으로 추가적인 헤더가 올 수 있다
Content-Type: text/html
Cache-Control: max-age=3600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36
이름과 값의 한 쌍으로 이루어져 있으며 위 예시에서
Content-Type, Cache-Control, User-Agent 는 헤더의 이름을 이름 옆에 콜론 ' : ' 우측은 각 헤더의 속성을 나타내는 값이다
Content-Type: text/html
= 응답하는 콘텐츠의 유형. "text/html"은 HTML 문서임을 나타냄
Cache-Control: max-age=3600
= 응답 캐시 동작을 제어. "max-age=3600"은 클라이언트 캐시가 해당 응답을 저장하는 최대 시간을 초 단위로 나타냄. 이 경우 3600초(1시간) 동안 응답을 캐시 할 수 있음
User-Agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.99 Safari/537.36
=클라이언트가 요청을 보낼 때 사용하는 사용자 에이전트. 여기서는 Mozilla Firefox 브라우저를 사용 중이며, 사용 중인 운영체제는 Windows 10이고, 웹 브라우저 엔진으로는 AppleWebKit을 사용하고 있으며, 브라우저의 버전은 Chrome 97.0.4692.99와 호환된다는 것을 나타냄
4. 메시지 바디 (Message Body): 요청에 대한 데이터로 get 요청에 대한 리소스내용, 서버에서 생성된 데이터등을 포함한다. JSON 형식의 데이터는 물론 HTML, 이미지등의 다양한 종류의 데이터를 포함할 수 있다
http의 특징
데이터를 일반 텍스트로 교환한다
암호화 되지 않은 데이터를 전송한다
통신상대를 확인하지 않는다 (신뢰성 떨어짐)
한번의 요청과 응답이 끝나면 서버와 클라이언트의 연결을 끊는다
기본적으로 80번 포트를 사용한다
http의 종류
| HTTP/1.1 | 최초의 HTTP 버전으로 요청, 응답을 순차적으로 처리(직렬처리)하기 떄문에 지연이 발생할 수 있습니다 전송시 Header 압축하지 않는다 (전송 데이터양이 많으면 오버헤드 발생) |
| HTTP/2 | HTTP/1.1 의 발전된 버전으로 요청, 응답을 병렬처리 할 수 있기 떄문에 지연이 줄고 로딩시간이 빨라집니다 또한 Header 데이터를 압축해서 데이터 전송량을 줄여줄수 있습니다 서버가 요청이 없어도 그전에 클라이언트에게 미리 콘텐츠를 보내 놔서 성능을 향상시킵니다 |
| HTTP/3 | TCP 대신 UDP기반의 QUIC 프로토콜을 사용합니다 QUIC는 연결 설정의 지연시간 최소화, 유지, 관리등의 기능이 있어 동영상 등의 서비스에 유리하다 |
오버헤드 : 어떤 작업을 수행하는 데 필요한 추가적인 비용이나 부담
HTTPS
Hypertext Transfer Protocol Secure 의 약자로
HTTP의 보안을 강화한 버전으로 HTTP의 요청, 응답을 SSL, TSL 기술으로 암호화한다
SSL과 TLS
SSL (Secure Sockets Layer) 은데이터 통신의 보안을 위해 개발된 프로토콜로
현재는 후속 버전인 TLS (Transport Layer Security)로 거의 대체되었다
https의 암호화 작동 방식
대칭 키
1. 두 당사자가 대칭 키를 생성해 나눠 갖습니다.
2. 송신자가 대칭 키를 사용해 데이터를 암호화 합니다.
3. 암호화된 데이터를 수신자에게 보냅니다.
4. 수신자는 받은 데이터를 대칭키를 사용해 복호화 합니다.
공개 키
1. 두 당사자가 한쌍의 공개키와 개인 키를 생성합니다. 공개키는 대중에게 공개됩니다.
2. 송신자가 수신자에게 데이터를 보낼때 수신자의 공개키를 사용해 암호화 합니다.
3. 수신자는 자신의 개인 키를 사용해 암호된 데이터를 복호화 합니다.
| 공개 키(비 대칭 키) | 대칭 키 |
| 누구나 사용할 수 있게 공개되는 키(공개키)와 소유자만 가지고 있는 키(개인키) 총 2개의 키가 있다 | 송신자와 수신자 모두 하나의 대칭키를 공유한다 |
| 암호화와 복호화에 필요한 키가 다르다. | 암호화와 복호화에 필요한 키가 같다. |
| 공개키는 누구에게나 공유하기 때문에 교환이 쉽고 개인키는 한개만 있어도 되기 때문에 관리가 쉽다 | 키를 교환할때 탈취당할 수 있어 교환하기가 어렵고 위험하다 그리고 사용자별로 각각 다른 키를 교환해야 하기 때문에 관리에 차질이 생길 수 있다 |
| 길이 제한이 있다 | 길이 제한이 없다 |
| 암호화 속도가 느리다 | 공개키에 비해 속도가 빠르다 |
| 인증 가능 무결성 가능 부인방지 가능 |
인증 부분적 가능 무결성 부분적 가능 부인방지 불가능 |
※ 공개키(비 대칭키)와 대칭키 ※
세션 키(session key)
하지만 실제로 우리가 사용하는 서버들은 공개키와 대칭키 두가지를 모두 사용하고 있다
공개키는 관리가 쉽고 보안성이 좋지만 대칭 키에 비해 컴퓨터의 자원이 낭비된다. 게다가 특정 개인 키로 너무 많은 데이터를 암호화하면 자료가 쌓여 암호해독이 더 용이해져 버린다.
그래서 우리가 사용하는 서버들은 TLS 핸드셰이크 과정에서 세션키를 생성해 사용한다.
TLS 핸드셰이크 의 과정
1. ClientHello 메시지: 클라이언트가 서버에게 통신을 시작하려는 의도를 알리기 위해 ClientHello 메시지를 보낸다. 이 메시지에는 클라이언트가 지원하는 TLS 버전, 암호 알고리즘, 압축 방법 등의 정보가 포함된다.
2. ServerHello 메시지: 서버는 클라이언트에게 응답하기 위해 ServerHello 메시지를 보낸다. 이 메시지에는 서버가 선택한 TLS 버전, 암호 알고리즘, 세션 ID 등의 정보가 포함된다.
3. 인증: 서버가 인증서를 클라이언트에게 제공한다. 클라이언트는 이 인증서가 신뢰할 수 있는 인증 기관에 의해 발급되었는지를 확인하고, 서버의 신원을 검증한다.
4. 키 교환: 서버는 클라이언트에게 임시 대칭키를 암호화하여 보낸다. 이 키를 클라이언트와 서버가 함께 사용하여 세션 키를 생성한다.
5. 세션 키 생성: 클라이언트와 서버는 임새 대칭키을 사용하여 세션 키를 생성한다. 이 세션 키는 대칭 키 암호화를 위해 사용된다.
6. 암호 매개변수 설정: 클라이언트와 서버는 통신에 사용할 암호화 알고리즘과 인증 방법을 협상한다. 이 과정은 클라이언트와 서버가 상호 동의하는 암호 매개변수를 설정하는 것을 포함한다.
7. 암호 매개변수 확인: 클라이언트와 서버는 핸드셰이크 과정에서 협상한 암호 매개변수를 확인하고, 이에 따라 통신을 설정한다.
이 끝나면 클라이언트와 서버간 전송되는 데이터는 세션 키를 통해 암호화 된다.
최대한 간단하게 설명하자면 공개 키를 사용해 암호화한 임시 대칭 키인 세션 키를 나눠갖는 것이다
세션키는 한번의 통신 세션에 사용하는 1회용 대칭 키이기 때문에 통신 세션이 끝나면 삭제된다
○ 여기서 키(KEY)란 암호화된 데이터를 복호화 할때 쓰는 비밀번호라고 보면 된다
○ HTTPS는 공통 키 방식과 비대칭 키 방식을 같이 사용한다
○ 공개키로 복호화 할수있는 데이터는 개인키로 암호화된 데이터기 때문에
어떤 서버에서 공개키로 복호화가 되는 데이터를 보낸다면 그 서버는 개인키를 가지고 있다고 검증할수 있다
○ 공개키를 인증해주는 CA가 있다. 이 회사들의 인증을 받은 공개키는 신뢰할 수 있는 사이트로 인증된다
https의 특징
브라우저와 서버가 데이터를 전송하기 전에 안전하게 데이터를 주고받을 수 있다
검색 엔진에서 https를 선호함으로서 SEO(검색앤진최적화)에 유리하다
암호화와 복호화 과정이 필요하기 때문에 속도가 느려질 수 있다 (하지만 미미한 차이이다)
인증서 발급및 유지를 위한 비용이 발생한다
기본적으로 포트는 443을 사용한다
| HTTP | HTTPS |
| 보안성이 낮다 암호화 하지 않는다 |
보안성이 높다 SSL/TLS를 사용하여 데이터를 암호화한다 |
| 기본 포트 80 | 기본 포트 443 |
| 인증서가 필요 X | SSL/TLS 인증서가 필요 |
| 데이터 무결성이 보증X | 데이터 무결성 보증O |
| 검색 엔진에 불리 | 검색 엔진에 유리 |
'CS 용어정리' 카테고리의 다른 글
| 절차지향과 객체지향 프로그래밍 (0) | 2024.04.12 |
|---|---|
| SDK와 IDE (0) | 2024.03.25 |
| 버그(Bug) 와 에러(Error) // 트래픽 (0) | 2024.03.21 |
| 백엔드(Back End) 와 Firebase (1) | 2024.03.19 |
