1. HTTP (HyperText Transfer Protocol)

HTTP는 하이퍼 텍스트 전송 프로토콜으로, 웹 서버 및 웹 브라우저 상호 간의 데이터 전송을 위한 응용계층 프로토콜이다.
통신 프로토콜을 쉽게 풀어보면 “우리는 이렇게 줄 테니 넌 그런식으로 받으면 되고 우린 너가 준거 이런식으로 받을게” 정도로 볼 수 있다.

URL

서버에 데이터를 요청하기 위해 입력하는 영문 주소

특징

1) 비-연결 지향

클라이언트가 서버에게 리소스를 요청한 후 응답을 받으면 연결을 끊어버리는 특징이다. 이로 인해 서버의 부담을 줄일 수 있지만, 리소스를 요청할 때마다 연결해야 하는 오버헤드 비용이 발생한다.
이를 해결하기 위해선, 요청헤더의 Connection: keep-alive 속성으로 지속적 연결 상태를 유지할 수 있다.
즉, 요청할 때마다 연결하지 않고 기존의 연결을 재사용하는 방식이다. HTTP 1.1 부턴 지속적 연결 상태가 기본이며 이를 해제하기 위해선 명시적으로 요청 헤더를 수정해야 한다.

2) 무상태성

각각의 요청이 독립적으로 여겨지는 특징으로, 서버는 클라이언트의 상태를 유지하지 않는다.
즉, 이전 데이터 요청과 다음 데이터 요청이 서로 관련이 없다는 말이다.
이러한 특징 덕에 서버는 세션과 같은 별도의 추가 정보를 관리하지 않아도 되고, 다수의 요청 처리 및 서버의 부하를 줄일 수 있는 성능 상의 이점이 생긴다.

HTTP 요청 메서드

클라이언트가 서버에 요청방법을 정의하는 것으로 주어진 리소스에 수행하길 원하는 행동을 나타낸다.

• GET: 서버에게 조회할 리소스를 요청한다.
• POST: 서버에게 본문(body)에 생성할 데이터를 삽입하여 전송한다
• PUT: 서버에게 본문에 수정할 데이터를 삽입하여 전송한다.
• DELETE: 서버에게 삭제할 리소스를 요청한다.
• PATCH: PUT과 비슷하지만 일부만 수정한다는 점에서 다르다.

1) 요청 헤더

• Host : 서버의 도메인 이름과 TCP포트 번호 (표준 포트는 생략 가능)
• Content-Type: POST/PUT 메서드를 사용할 때 본문의 타입
• If-Modified-Since: 명시한 날짜 이후로 변경된 리소스만 획득
• Origin: 요청이 어느 도메인에서 왔는지 명시, 서버의 Access-Control-* 속성에 필요
• Cookie: 서버의 Set-Cookie로 설정된 쿠키 값

2) 응답 헤더

• Access-Control-* : CORS를 허용하기 위한 웹사이트 명시
• Set-Cookie : 클라이언트에 쿠키 설정
• Last-Modified : 요청한 리소스가 마지막으로 변경된 시각
• Allow : 요청한 리소스에 대해 가능한 메서드들 ( Allow: GET, HEAD )

응답 상태코드

서버가 클라이언트에게 요청을 받으면 응답상태에 따라서 다른 상태코드를 클라이언트에게 돌려준다.

• 10x (요청에 대한 정보) : 요청을 받았으면 작업을 계속한다.

• 20x (성공)

  • 200(성공)
  • 201(새 리소스 작성)
  • 202(요청 접수, 아직 처리는 안함)

• 30x (리다이렉션): 클라이언트가 요청을 마치기 위해 추가적인 동작을 취해야 한다.

  • 300(여러개의 응답, 선택해야 함)
  • 301(영구이동, 요청한 페이지가 영구적으로 이동됨)
  • 302(임시이동, 현재 응답임, 다른 페이지이긴 하지만 임시적임

• 40x (클라이언트 오류)

  • 401(권한 없음)
  • 403(금지됨, 리소스에 대한 권한 없음)
  • 404(찾을 수 없음, 서버에 없는 페이지)

• 50x (서버 오류)

  • 500 (내부 서버오류)
  • 501 (요청 수행 기능 없음, 메서드 인식불가)
  • 503 (서비스 사용불가)

2. HTTPS (HyperText Transfer Protocol over TLS/SSL)

HTTPS는 기존의 HTTP를 암호화한 프로토콜로 보안이 강화된 버전이다. 서버와 주고받는 데이터가 암호화되기 때문에 웹사이트에 추가적인 보호를 제공한다. 즉, 개인 데이터를 훔치거나, 해킹하거나 볼 수 없도록 작동한다.

HTTPS 확인 방법

브라우저에서 URL을 확인하여 웹사이트에 HTTPS 보호 기능이 있는지를 확인할 수 있는데 위와 같이 도메인 이름 앞에 자물쇠 아이콘이 있으면 사이트는 HTTPS로 인해 안전한 것이다.

필요 개념

1) 공개키(Publick Key)와 비밀키(Private Key)

공개키는 모두가 볼 수 있는 키이며 비밀 키는 소유자만이 가지고 있는 키로 암/복호화에 사용된다.

2) 대칭키 암호화

서버와 클라이언트가 암호화/복호화에 동일한 비밀키를 사용하는 방식, 키를 공유하는데 어려움이 있으나 속도가 빠르다.

3) 비대칭키 암호화

서버와 클라이언트가 암호화/복호화에 각가 다른 비밀키를 사용하는 방식, 공개키를 통해서 암호화를 하고 비밀키를 통해서 복호화를 한다.
공개키는 공개해도 상관 없으니 키 관리에 어려움이 없으나, 속도가 느리다.

4) 인증기관(Certificate Authority, CA)

클라이언트가 접속을 요청한 서버가 의도한 서버가 맞는지 인증해주는 역할을 하는 보증된 기업들이다.
클라이언트는 서버에 요청을 해서 CA가 발급한 인증서를 받은 뒤 CA의 공개키로 복호화하여 신뢰할 만한 인증서인지 검증한다.

동작 방식

HTTPS는 대칭키 암호화를 사용하며 다음과 같은 과정을 거친다.

1. 클라이언트가 서버에게 접속요청을 하면 서버는 CA에서 발급받은 인증서를 보낸다.

2. 클라이언트는 인증서를 받아 CA의 공개키로 복호화하여 접속요청한 서버가 신뢰할만한지 검증한다.

   • 브라우저가 CA의 공개키로 복호화가 가능하다는 것은 그 데이터가 공개키와 쌍을 이루는 비공개키를 통해 암호화되었음을 인증하는 것과 같다.

3. 복호화가 되면 인증서가 신뢰할 만하기 때문에 데이터를 주고 받을 대칭키를 생성한다.

4. 대칭키를 서버의 공개키로 암호화하여 서버에게 전송한다.

5. 서버는 자신의 비밀키로 클라이언트가 보낸 대칭키를 복호화해 데이터를 주고 받는다.

HTTPS의 검색엔진 최적화(SEO) 효과

1) 더 나은 사용자 경험 제공 및 사이트 체류시간 증가

사용자들이 검색을 통해 웹 사이트에 방문했을때 수많은 팝업 광고 등이 먼저 등장하게 된다면 그들은 더 이상 사이트에 머물지 않을 것이다.
또한 그런 사이트를 보여준 Google을 신뢰하지 않게 될지도 모르며 당연히 Google은 그런 평판을 원하지 않을 것이다.

SSL 인증서가 없는 안전하지 않은 사이트는 Google이 사이트에 대해 높은 순위를 달성하기 위해 설정한 “고품질의 신뢰할 수 있는 안전한 웹 사이트” 기준에 맞지 않는다. 실제로 Google은 안전하지 않은 사이트에 대해 매우 엄격하므로 사용자가 SSL 인증서가 없는 사이트를 방문할 때 사용자에게 알리고 암호화되지 않은 웹 사이트에 “Not secure”, 즉 “안전하지 않음”이라는 레이블을 지정한다.

위와 같은 경고 표시는 사용자가 사이트를 떠나게 만드는 이유가 될 수 있으며 이는 좋은 사용자 경험이나 높은 검색결과 순위로 이어지지 않게 될 것이다.

2) 사이트 로딩 속도 개선

Google의 조사에 따르면 페이지를 로드하는 데 3초 이상 소요되면 방문자의 53%가 사이트를 이탈한다고 한다.
이처럼 사이트 속도는 중요한 랭킹팩터 중 하나이다.

이때 HTTPS는 HTTP보다 300% 이상 더 빠르게 로딩되기 때문에 SEO적으로 매우 유리하다.

3) SEO 전략 확인 및 검증

정기적으로 SEO 적용 현황을 확인하고 검증함으로써 SERP 순위에 영향을 미치는 요소들을 파악하여 SEO 전략 조정이 필요한데 이때, HTTPS 전환은 도움이 될 수 있다.

사이트가 안전하지 않다고 판단되는 HTTP 사이트는 리퍼러 정보가 제거되어 트래픽 소스를 확인할 수 없다.
즉, SNS, 자연 검색 또는 유료 광고를 통해 당신의 사이트가 추천되었을때 “직접” 들어온 많은 방문자들의 경로를 파악하기 어렵다.

반면 HTTPS를 사용하는 보안 웹사이트는 분석 대시보드에서 해당 리퍼러 정보를 보호하고 표시해주기 때문에 웹 사이트에 대한 최적의 트래픽 소스를 명확하게 찾아내고 정확하게 확인할 수 있다.