HTTP ? 이건 뭐고 HTTPS와 차이는 뭐야?
결론
HTTPS vs HTTP
- HTTPS의 용도와 HTTP와의 차이점
HTTPS(HyperText Transfer Protocol Secure)는 기존 HTTP에서 Secure(보안)이 추가된 방식입니다.
HTTP의 확장 버전 또는 더 안전한 버전입니다. HTTPS에서는 브라우저와 서버가 데이터를 전송하기 전에 안전하고 암호화된 연결을 설정합니다.
네트워크 프로토콜 암호화 방식을 사용하여 클라이언트가 웹 서버에 데이터 전달시 암호화를하여
제 3자가 정보를 훔치지 못하도록 방지. HTTPS는 HTTP 요청 및 응답을 SSL 및 TLS 기술에 결합합니다.
차이점 요약
| HTTP | HTTPS | |
| 의미 | Hypertext Transfer Protocol | Hypertext Transfer Protocol Secure |
| 기본 프로토콜 | HTTP/1과 HTTP/2는 TCP/IP를 사용합니다. HTTP/3은 QUIC 프로토콜을 사용합니다. | HTTP 요청 및 응답을 추가로 암호화하기 위해 SSL/TLS와 함께 HTTP/2 사용 |
| 포트 | 기본 포트 80 | 기본 포트 443 |
| 용도 | 이전 텍스트 기반 웹 사이트 | 모든 최신 웹 사이트 |
| 보안 | 추가 보안 기능 없음 | 퍼블릭 키 암호화에 SSL 인증서 사용 |
| 이점 | 인터넷을 통한 통신 지원 | 웹 사이트에 대한 권위, 신뢰성 및 검색 엔진 순위 개선 |
HTTP ?
HTTP: Hyper Text Transfer Protocol:
하이퍼 텍스트를 전송하는 통신 규약.
웹상에서 네트워크로 서버끼리 통신을 할때 어떠한 형식으로 서로 통신을 하자고 규정해 놓은
"통신 형식" 혹은 "통신 구조"그러면 삐삐인가 ?
서버와 클라이언트가 인터넷상에서 데이터를 주고 받기위한 프로토콜을 이야기하며
TCP / IP 프로토콜 기반의 응용 계층 프로토콜입니다.
어떠한 종류의 데이터도 전송할 수 있도록 설계되어있습니다.
- HTML, TEXT
- IMAGE, Media, File
- JSON, XML …
기반 프로토콜
- TCP: HTTP/1.1, HTTP/2는 TCP 기반이다.
- UDP: HTTP/3
현재는 대부분 HTTP/1.1을 사용하나 HTTP/2, HTTP/3도 점차 증가하고 있다.
- TCP 통신은 3 way handshake 때문에 신뢰성과 연결성은 보장하지만, 이 과정에 걸리는 시간만큼 속도가 떨어질 수 밖에 없다. 그렇기에 HTTP/3에서는 UDP 프로토콜을 애플리케이션 레벨에서 재설계를 해서 속도를 높혔다
HTTP 의 특징
- 클라이언트 서버 구조
클라이언트는 요청(Request)을 보내고 서버는 요청에 대한 결과를 응답(Response)하는 구조입니다.
이렇게 클라이언트와 서버를 분리함으로써 각각의 역할에 맞는 기능만 수행하면 되기에 각 역할은 자신의 기능수행에 집중할 수 있습니다.
이슈가 생겼을때도 이슈가 생긴 역할에서만 이슈를 관리하면 됩니다.
2. 무상태 프로토콜(Stateless Protocol)
통신이 끝나면 상태를 유지하지 않는 특징입니다.
서버가 클라이언트의 상태를 보존하지 않아클라이언트와 서버의 결합도가 매우 낮습니다.
중간에 서버를 변경해도 되기에 스케일 아웃(수평 확장) 이 편리합니다.
참고: 무상태 프로토콜의 실무적 한계
로그인서비스와 같이 상태가 있어야 하는 서비스도 있기에 설계적 한계도 있고, 매번 모든 데이터를 보내야 한다는 점도 문제가 될 수 있어서 로그인은 쿠키,세션 등을 이용해 상태를 유지하고는 합니다.
3. 비 연결성(Connectionless)
클라이언트가 요청을 한 후 응답을 받으면 그 연결을 끊어버리는 특징입니다.
클라이언트와 서버가 요청(Request)시에만 연결이되며 요청에 맞는 응답(Response)을 보내고 그 외에는 연결을 유지하지 않고 끊습니다. 계속 연결을 유지하는것도 결국 비용이고 연결을 최소한으로 함으로써 비용을 절약하는 장점을 가집니다.
4. 단순함, 확장 가능
- 확장성 덕분에, 오늘날 하이퍼텍스트 문서 뿐만 아니라 이미지와 비디오 혹은 HTML 폼 결과와 같은 내용을 서버로 포스트(POST)하기 위해서도 사용되고 필요할 때마다 웹 페이지를 갱신하기 위해 문서의 일부를 가져오는데 사용될 수도 있습니다.
5. HTTP 메시지 구조를 가짐
| HTTP 메시지 구조 | ||
| Start-line | 시작라인 | 혹은 응답이 작성되며 둘의 형태가 약간 다름 |
| Header | 헤더 | - HTTP 전송에 필요한 모든 부가정보를 가지고 있다. (ex: 메시지 바디의 내용 및 크기정보, 압축, 인증 등) - 표준 헤더가 매우 많음. |
| Empty Line | 공백 라인(CRLF) | 공백(Enter) Message Body와 구분하는 역할 |
| Message Body | 메시지 본문 | - 실제 전송할 데이터 - HTML 문서, 이미지, 영상, JSON 기타 byte로 표현가능한 모든 데이터 |
CMD 창을 열어 CURL 을 통해서 다음 커맨드를 입력시 HTTP의 메시지 구조를 확인할 수 있습니다.
curl -v www.google.co.kr?query=http구조
# 예시HTTP 작동방식
- HTTP 는 서버/클라이언트 모델
작동방식은 요청(Request) 과 응답(Response)으로 이루어짐
- 클라이언트가 먼저 서버에 요청을 보낸다.
- 요청받은 서버가 클라이언트에게 응답을 보낸다.
- 무상태 프로토콜
요청과 응답의 과정이 끝나면 연결을 끊습니다.
→ 클라이언트의 바로 다음 요청을 직전에 요청한 클라이언트인지 알 수 없습니다.
이러한 HTTP 특징의 장단점은 다음과 같습니다.
| 장점 | 단점 |
| 불특정 다수 대상 서비스에 적합 | 연결을 끊기 때문에 클라이언트가 이전에 어떤 요청을 했는지 알 수 없음(ex..로그인) |
이러한 문제를 해결하기위해 연결을 끊어도 정보가 사라지지 않고 유지할 수 있는
쿠키(Cookie) 같은 기술이 등장
. URL ?
URI는 식별하고, URL은 위치를 가르킨다.
- URI : 통합 자원 식별자 Uniform Resource Identifier
특정 리소스를 식별하며 웹 기술에서 사용하는 논리적 또는 물리적 리소스를 식별하는 고유한 문자열 시퀀스입니다.(위치와 이름 모두 포함) - URL : Uniform Resource Locator
흔히 웹 주소라고도 하며, 컴퓨터 네트워크 상에서 리소스(문서,파일)가 어디 있는지 알려주기 위한 규약으로 URI의 서브셋입니다.
URL의 구성은 크게 세가지 부분으로 나눠집니다.- 1. 프로토콜 종류
- 2. 자원이 있는 서버의 IP 주소, 도메인 주소
- 3. 자원위치(경로)
| 동적 URL | 정적 URL |
| “?” 나 “&” 와 같이 쿼리에 따라 값이 다르게 나오며 매개변수 이름 및 값으로 이루어져 있다. | 동적 URL과 달리 매개변수 이름 및 값으로 이루어져 있지 않다. |
| 요청에 대해서 각각 다른 내용을 보여준다. 사용자(클라이언트)가 URL 을 통해 서버에 웹 페이지를 요청했을 때, 서버는 사용자에 맞는 HTML 문서를 생성하여 사용자에게 응답하게 된다 ex) 온라인 쇼핑몰의 장바구니, 최근 본 상품, 추천 물건, 사이트의 회원가입, 로그인 등 |
항상 같은 내용을 보여주는 웹페이지로 사용자가 URL을 통해 서버에 웹 페이지를 요청하였을 때, 서버 안에 이미 만들어져 있는 HTML 문서를 사용자에게 보여주는 경우 ex) 백과사전의 내용과 같이 항상 같은 내용을 보여준다. |
- 접근 프로토콜 : https, http 어떤 방식으로 자원에 접근할 것인가 하는 규칙
- IP 주소 또는 도메인 이름 :
하드웨어 서버를 찾기위해서는 IP나 도메인이 필요합니다.
IP 주소(172.17.X.XXX ), 도메인 주소(naver.com, OOO.tistory.com)
하드웨어 서버를 찾고 나면 해당 서버안에 있는 소프트웨어 서버를 찾기 위해 포트값이 필요합니다.
IP와 포트가 헷갈린다면 다음의 간단한 예를 통해 알아보겠습니다.
| 컴퓨터 | OO 타워 | |
| (하나만 존재) | IP | OO 타워 주소 |
| (여러개 존재) | 포트 | 각 계열사 |
각 회사가 몇층에 있는지 정확히 알지 못하면 OO 타워의 주소를 알더라도 찾아갈 수 없는 것처럼
각 서버는 각 하나의 포트만 차지하고 있어서 포트번호가 서버마다 달라야 합니다.
즉, 하나의 물리서버에는 여러개의 소프트웨어 서버가 동작할 수 있으며 포트값(0보다 큰 숫자)이 각각 다르게 동작해야 합니다.
- 자원위치(문서의 경로 및 문서이름) : 리소스 경로로 계층적 구조로 되어 있다.
즉 상세주소에 해당하며 웹 페이지마다 다른 경로를 가짐- /wiki
- /wiki/spaces
- /wiki/spaces/ESC
- /wiki/spaces/ESC/pages
- /wiki/spaces/ESC/pages/480313345
실제 웹 동작
- 클라이언트가 원하는 서버에 접속
- 클라이언트가 서버에 요청
- 서버가 요청에 따른 응답 결과를 클라이언트한테 응답
- 응답이 끝나고 나면 서버와 클라이언트의 연결이 끊김
요청 데이터 포맷
클라이언트가 서버에 요청할때 정해진 규칙이 있으며
웹 브라우저는 요청 메시지라는 것을 갖습니다.
요청 메시지는 요청 헤더, 빈줄, 요청 바디 이렇게 세부분으로 나뉩니다.
- 요청헤더
- 요청 메서드 : GET, POST 등등..
- 요청 URI : 요청하는 자원의 위치 명시 HTTP 프로토콜 버전 : 웹브라우저가 사용한는 프로토콜 버전 명시
- 요청바디
- GET방식은 요청 바디가 없다.(자원 등 가져가야 할 부분을 URI에 붙인다.) POST나 PUT사용시 들어온다.
응답 데이터 포맷
- 응답헤더
응답 HTTP 프로토콜 버전 / 응답 코드 / 응답 메시지
날짜
웹서버 이름 버전
콘텐츠 타입 등 - 응답바디
응답 리소스 데이터
HTTP 메서드 활용
- 요청 메소드 종류
- ★ GET (SELECT) :
정보를 요청하기 위해서 사용합니다. (SELECT)
데이터를 서버로부터 받아올 때 사용하며 가장 간단하고 많이 사용됩니다.
받아올 때만 사용하기 때문에 request body 를 안보내는 경우가 많습니다. - ★ POST (INSERT) :
정보를 밀어넣기 위해서 사용합니다. (INSERT)
데이터를 생성/수정/삭제 할 때 주로 사용됩니다.
생성 및 수정 할 때 사용하기 때문에 대부분 request body를 포함해서 보냅니다. - PUT (UPDATE) :
정보를 업데이트하기 위해서 사용합니다. (UPDATE)
데이터를 생설할 때 사용되며 POST와 비슷합니다.
POST에 밀려 잘 사용안되는 추세입니다. - DELETE (DELETE) :
정보를 삭제하기 위해서 사용합니다. (DELETE)
PUT과 마찬가지로 POST에 밀려 잘 사용안되는 추세입니다. - HEAD (HTTP) :
(HTTP)헤더 정보만 요청합니다. 해당 자원이 존재하는지 혹은 서버에 문제가 없는지를 확인하기 위해서 사용합니다. - OPTIONS :
웹서버가 지원하는 메서드의 종류를 요청한다.
EX) /update uri 에서 어떤 메소드를 지원하는지(POST ? PUT?)에 대해 먼저 OPTIONS를 요청해 확인할 수 있습니다. - TRACE :
클라이언트의 요청을 그대로 반환한다. echo 서비스로 서버 상태를 확인하기 위한 목적으로 주로
사용합니다.
- ★ GET (SELECT) :
- HTTP 메소드의 속성
- 안전(Safe)
- 호출해도 리소스를 변경하지 않는 특성
- 멱등(Idempotent)
- 동일한 요청을 여러 번 보내도 한 번 보내는 것과 같은 것올바르게 구현한 GET, PUT, DELETE 메소드는 멱등성을 지녀야 한다.
- 외부 요인으로 중간에 리소스가 변경되는 것을 고려하지 않고 해당 요청을 기준으로 고려한다
- ex)
DELETE /members/100 → 200
DELETE /members/100 → 404
DELETE를 여러 번 호출하면 응답 코드는 달라질 수 있지만, 100번 member가 삭제된 것은 동일
- 캐시가능(Cacheable)
- 응답 결과를 서버에 캐시 해서 사용해도 되는 메소드
- GET, HEAD, POST, PATCH가 가능하지만 실무에서는 구현이 어렵기 때문에 GET, HEAD 정도만 캐시 하여 사용
- 안전(Safe)
- HTTP API 설계 예시 - 고객 관리 시스템
- POST 신규 자원 등록 특징
- 클라이언트는 등록될 리소스의 URI를 모른다.
ex) /customers/100 => 100 이 URI - 서버가 새로 등록 된 리소스 URI를 생성해준다.
- 컬렉션 => /customer
서버가 관리하는 리소스의 디렉토리
서버가 리소스의 URI를 생성하고 관리
여기서 컬렉션은 /customer
- 클라이언트는 등록될 리소스의 URI를 모른다.
- API 설계 post 기반 등록
- 고객 목록/customers->GET
- 고객 등록/customers ->POST
- 고객 조회/customers/{id}->GET
- 고객 수정/customers/{id}->PATHC, PUT, POST
- 고객 삭제/customers/{id} -> DELETE
- POST 신규 자원 등록 특징
POST 등록 VS PUT 등록
PUT을 사용할 때 POST와 다른 점은 클라이언트가 직접 리소스의 URI를 지정해줍니다.
즉, 클라이언트가 생성된 리소스의 URI를 다 알고, 본인이 관리한다는 의미입니다.
반면에, POST로 등록할 때는 /customers만 넘기고 끝났고 리소스의 URI는 서버가 알아서 만들어서 클라이언트 쪽으로 내려주었습니다.
POST => 신규 데이터 등록 시 클라이언트가 서버에 요청
PUT => 리소스 URI 다 알고 등록해야함, OOO.jpg 의 위치를 클라이언트가 다 알고 서버에 그 위치까지 찍어서 보내주며 이런 스타일의 관리를 스토어(Store)라고 합니다.
대부분 POST 기반의 신규 자원 등록방식을 사용(컬렉션)