HTTP는 팀 버너스리에 의해 발명된 WWW(월드와이드웹)에 내지 된 프로토콜이다.

HTTP를 간단하게 설명하면 웹에서 데이터를 전송하는 약속, 규칙이라고 생각하면 된다.

 

CERN(유럽입자연구소)에서 일하던 팀버너스리에 의해 HTTP가 제안이 되었다.

 

사용자가 서버(웹사이트)에 어떤 정보를 얻기위해서는 요청을 해야 하는데 이때 HTTP에서 제공하는 메서드와 헤더에 입력된 정보를 기반으로 정보를 응답받는다.

 

이런 식으로 우리가 사용하는 웹사이트가 정보를 주고받는다.

 

요청

GET /restapi/v1.0 HTTP/1.1
Accept: application/json
Authorization: Bearer UExBMDFUMDRQV1MwMnzpdvtYYNWMSJ7CL8h0zM6q6a9ntw

응답

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Encoding: UTF-8
Content-Length: 138
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
ETag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Connection: close

<html>
<head>
  <title>An Example Page</title>
</head>
<body>
  Hello World, this is a very simple HTML document.
</body>
</html>

요청 메서드(HTTP 동사)

주어진 리소스(동영상, 메시지, 뉴스글 등)에 수행하길 원하는 행동을 나타낸다. 각각의 메서드는 서로 다른 의미를 구현

HTTP 메서드 RFC 간단설명
GET RFC 7231 해당 메서드는 특정 리소스를 받기만 요청한다.
POST RFC 7231 특정 리소스를 제출할 때 사용한다. 서버의 상태 변화를 일으킨다.
PUT RFC 7231 특정 리소스로 새롭게 생성하거나, 대상 리소스를 대체한다.
DELETE RFC 7231 특정 리소스를 삭제한다.
PATCH RFC 5789 해당 메서드는 리소스의 부분만을 수정하는데 사용한다.

이 외에도 HEAD, CONNECT, OPTIONS, TRACE가 존재한다.

 

응답 상태 코드

HTTP 요청이 성공적으로 완료되었는지 알려주는 코드입니다. 숫자로 사용자에게 알기 쉽게 표시를 해주며 총 5개의 그룹으로 나누어진다.

  • Informational responses(조건부응답) 100 ~ 199
  • Successful responses(성공응답) 200 ~ 299
  • Redirection messages(재요청응답) 300 ~ 399
  • Client error responses(요청오류응답) 400 ~ 499
  • Server error responses(서버오류응답) 500 ~ 599

여기서는 자주 접하거나 알아두면 좋은 코드들을 위주로 작성했다.

1xx (조건부응답) : 요청은 잘 받았고 받은 요청을 처리하고 있는 중이다.

해당 상태 코드는 RFC2616에 기록된 내용으로 보면 요청된 내용은 지금까지 모두 정상이며 요청이 계속되거나 이미 완료가 된 상태이면 요청을 무시해라고 적혀있다. 그래서 HTTP/1.0 버전 이후로 웹을 사용하는 사람들은 해당 응답 코드를 볼 수 없다.

 

100 (계속)

요청한 상태는 괜찮으며 첫 번째 요청을 받았으니 나머지는 기다리고 있다를 나타낸다.

 

2xx (성공응답) : 요청이 성공적으로 완료되었습니다.

200 (성공)

요청한 내용이 제대로 처리되었고 원하는 리소스를 제공받았다.

 

201 (생성)

요청이 성공적으로 완료하였고 서버(웹사이트)에 새로운 리소스를 생성했다.

 

204 (콘텐츠없음)

정상적으로 요청을 마무리했지만 리소스(콘텐츠)를 제공하지 않는다.

 

3xx (재요청응답) : 요청을 완료하기 위해서 추가 동작을 취해야 한다.

300 (여러선택 항목)

요청에 대해서 하나 이상의 응답이 가능하다. 요청자는 그중에 반드시 하나를 선택해야 한다.

 

4xx (요청오류) : 잘못된 문법을 사용자가 사용하여 서버가 상태를 이해하지 못한다.

400 (잘못된요청)

잘못된 문법으로 인하여 서버가 요청을 이해하지 못한다.

 

401 (인증없음)

요청했던 해동이 인증(권한)이 필요하여 사용자는 해당 요청을 위해서 인증을 받아야 한다.

 

403 (접근금지)

사용자가 해당 리소스에 인증 여부와는 관련 없이 접근할 권리가 없다. (401은 인증 실패, 403은 인가 실패)

 

404 (찾을 수 없음)

서버가 요청한 페이지(리소스)를 찾을 수 없다. 알려지지 않는 URL을 의미한다.

 

5xx (서버오류) : 유효한 요청을 서버가 제대로 수행하지 못했을 때를 의미한다.

500 (내부 서버 오류)

서버에 문제가 발생한 것으로 요청을 수행할 수 없다.


위에 입력된 상태 코드와 요청 메서드 말고도 더 다양하니 참고자료에 적힌 사이트에 들어가서 직접 보는 것을 권장합니다.

 

참고자료

HTTP - 위키백과, 우리 모두의 백과사전 (wikipedia.org)

HTTP 상태 코드 - HTTP | MDN (mozilla.org)

HTTP/1.1: Status Code Definitions (w3.org)

rfc2616 (ietf.org)

JWT는 "Json Web Token"의 약자로써 RFC7519로 인터넷표준 암호화 토큰이다. 해당 기술은 세션기반의 인증보다는 Stateless기반(비세션기반)의 웹페이지에서 주로 사용을 한다고 한다.

 

 세션기반의 인증은 클라이언트가 로그인시 해당 유저의 정보를 서버의 세션에 저장을 한뒤 서버의 세션값을 유저에게 보낸다. 그리고 정해진 시간안에서는 세션이 계속 유지가되면서 서버와의 데이터전송이 가능하다. 

 

다만 해당 세션기반의 가장 치명적인 약점은 바로 "확장성"이다.

 

예를들어 A라는 웹애플리케이션을 처음 설계를 할때는 사용자가 많지않을꺼라 생각해서 100명정도의 수용량을 계산하여 설계했다.  그런데 예상치 못한 인기에 B라는 웹애플리케이션을 또 하나 배치하여 분산(이런 기술을 로드밸런서라고 한다)을 시키기로 하였다.

로드밸런서란 여러명의 이용자가 하나의 서버에 접속을 하여 서비스에 지장을 주는 것을 방지하기 위한 기술로 일정한 수용량이 되면 로드밸런서가 일부 사용자를 다른 서버로 이동시켜서 서버에 부하를 방지하는 기술이다.

 

 여기까지는 크게 문제가 없다. 로드밸런서로 서버의 부하도 막고 아무런 문제가 없어보인다. 진짜 문제는 여기서부터인데 A와 B는 같은 웹애플리케이션을 실행시키지만 결론적으로만 생각해보면 A와 B는 다른 서버이기 때문에 둘은 세션 ID값이 다를 수 밖에 없다. 그래서 A라는 곳에서 놀다가 B라는 곳으로 이동을 하게되면 다른 ID값이기 때문에 다시 인증을 해야하는 경우가 온다.

물론 세션 ID값을 공유하거나 다루는 서버를 만들고 A와 B를 연결하는 방법등도 존재한다고 한다.. 여기서는 다루지 않는다.

그래서 사람들은 인증방식의 정보를 세션이 아닌 사용자에게 주면 해결이 되는게 아닌가?에서 나온 방법이 바로 JWT이다.

구조는 HeaderPayloadSignature 이렇게 3개로 구성이 되어있다.

우선 HEADER 부분을 보면 "alg": "HS256"이 부분이 눈에 띈다. 여기서 HS256은 JWT의 암호화방식은 HMAC(HS256 등), RSA, ESDSA가 있다. 그리고 "typ": "JWT"로 JWT임을 증명한다.

 

그 다음은 PAYLOAD는 사용자와 서버 간 주고 받기로 한 데이터들로 구성이 되어있다. PAYLOAD에 있는 속성들은 클레임 셋(Claim Set)이라고 부른다.

 

마지막으로 SIGNATURE는 위의 HEADER와 PAYLOAD의 값들을 "alg"에 정의된 방식으로 암호화하고 Base64로 인코딩을 한다. 그리고 위의 사진에 Encoded부분을 보면 .(점)으로 HEADER, PAYLOAD, SIGNATURE를 합치면 마침내 JWT가 완성이 되는것이다.

 

JWT 공식 페이지 : JSON Web Tokens - jwt.io

 

JWT.IO

JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.

jwt.io

포트란?

java 같은 언어로 웹애플리케이션을 제작을 한 뒤 해당 애플리케이션으로 실행을 하면 대부분 이렇게 접속을 한다.

http://localhost:8080

여기서 말하는 localhost는 해당 애플리케이션을 실행한 자신을 말한다. 그리고 포트번호는 옆에 적혀있는 ":8080" 이 부분이다. 즉 해당 프로그램은 localhost의 8080포트로 접속을 하는 것이다.

 

 자기자신의 컴퓨터에서 실행을 하고 '혼자' 사용을 하는 경우에는 위와 같은 방식으로 접속을 해도 아무런 문제도 없다.

하지만 해당 방식으로는 상대방(고객)을 자신이 만든 프로그램으로 데리고 오기에는 곤란한다. 

 

 그래서 상대방도 접속을 할 수 있는 "약속된" 문을 열어두고 그곳에서 자신이 만든 프로그램을 누구나 이용할 수 있도록 한다.

 

포트번호 구분

포트는 크게 세 종류로 구분한다고 한다.

  • 0 ~ 1023번까지 포트를 "잘 알려진 포트"
  • 1024 ~ 49151번까지는 "등록된 포트"
  • 49152 ~ 65535번까지는 "동적 포트"

포트번호같은 경우는 몇개는 이미 사용을 이렇게 하기로 정해져있다.

 

 대표적으로 HTTP는 80, HTTP는 443포트로 이렇게 사용하도록 약속이 되어있다. 또한 80포트와 443포트로 접속을 하게되면 위에서 나온 예시와는 다르게 포트번호가 보이지 않게 된다. 왜 보이지않냐?에 대해서는 크게 의문을 가질 필요는 없다고 생각한다.

 

왜냐하면 규칙이 그렇게 정해져있기 때문이다.

만약 자세한 내용을 찾고싶으면 RFC 2616의 3.2.2 http URL부분에 명시되어 있다.

HTTPS의 문서는 이곳을 참고하면 된다.

 

또한 Mysql의 포트는 3306, 톰캣은 8080 등등.. 프로그램들은 포트번호를 동적으로 가지기도 한다. 

'정보게시판 > ' 카테고리의 다른 글

HTTP : 응답과 요청  (0) 2022.06.26
JWT란?  (1) 2022.06.26
Apple WWDC 개발자 컨퍼런스 소개  (0) 2022.06.26
테스트를 위한 더미 파일 생성하기  (0) 2022.06.18
Base64 인코딩 방법  (0) 2022.06.14

애플의 글로벌 개발자 컨퍼런스가 2022년 6월 7일을 기준으로 열리며, 많은 내용들이 소개되었습니다. 

 

이 중 웹 개발자들에게 중요한 소식들을 모아둔 영상이 있어

 

함께 공개하며 내용을 요약하여 정리해 보겠습니다. 

 

1. 애플의 PWA 푸시알림 지원 발표 

 

PWA는 Progressive Web Application, "주기적 백그라운드 동기화 API"로 웹 페이지를 앱처럼 사용할 수 있게 만드는 기술입니다. 

 

안드로이드는 PWA를 적극 지원하였으나, IOS는 앱스토어 수수료 문제때문에 기능을 제한한 점이 많았는데 2023년에 푸시알람을 구현할 수 있는 api 제작을 선언하며 PWA를 지원하기로 하였습니다. 

 

이제 어플리케이션 개발에서도 웹 개발자의 수요가 더더욱 늘어날 것으로 생각됩니다. 

 

2. FIDO 지원을 통한 비밀번호 없는 세상 

 

FIDO는 비밀번호를 대체할 수 있도록 만들어진 인증방법의 표준을 정하기 위한 협의회입니다. 

 

이 표준에 따라서 애플 역시 password가 아닌 Passkey 방식으로 바뀌어 나갈 것이라고 합니다. 

 

이 기술은 다른 앱( 특히 스마트폰 ) 과 연동되어 인증을 관리하기 때문에 

 

메인 DB정보가 유출된다고 해도 사용자의 인증정보가 유출될 염려가 없고 

 

특히 애플은 프록시 기반으로 컴퓨터와 휴대폰을 블루투스로 연결하여 인증을 진행하도록 하여 

 

인증정보 중간에 개입할 여지를 최소화한다고 합니다. 

 

또 가짜 웹사이트를 이용하여 비밀번호를 탈취할 수 있던 password에서 

 

FIDO를 이용하면 웹 도메인 별로 다른 암호화가 적용되기 때문에 파싱사이트가 인증을 성공시킨다 하더라도 

 

그 인증은 실제 도메인 ( EX, Naver )에서 사용할 수 없는, 오로지 파싱사이트에서만 작동하는 인증이라고 합니다. 

 

기존의 비밀번호가 가지고 있던 요청 개입, 파싱 웹사이트 위험, DB 인증정보 유출 등에서 벗어날 수 있는 방법으로써 

 

다른 대기업들도 널리 지원할 예정이고, 애플도 이에 협력하기로 했다고 합니다. 

 

 

FIDO는 Private key와 Public Key를 이용하여 각 기기간의 과제를 내고

 

그걸 푼 기기만을 통과시키는 방법을 사용한다고 하는데, SSH의 인증방식과도 상당히 닮아있는 것 같습니다. 

 

참고한 영상 및 사이트를 올리며 이만 마치겠습니다. 

 

애플의 2022년 6월 개발자 컨퍼런스, 꼭 한번 확인해보시길 바랍니다. 

 

참고 자료 

 

 

FIDO Alliance 공식 webSite

 

FIDO Alliance - Open Authentication Standards More Secure than Passwords

FIDO Alliance is focused on providing open and free authentication standards to help reduce the world’s reliance on passwords, using UAF, U2F and FIDO2.

fidoalliance.org

 

 

 

노마드 코더 : 웹 개발자들 무조건 보세요! 애플의 큰 그림!

 

WWDC 2022 - 6월 7일 | Apple 

 

'정보게시판 > ' 카테고리의 다른 글

JWT란?  (1) 2022.06.26
네트워크 통신의 포트(Port)  (1) 2022.06.26
테스트를 위한 더미 파일 생성하기  (0) 2022.06.18
Base64 인코딩 방법  (0) 2022.06.14
Redis, 인메모리 데이터베이스(In-Memory Database)  (0) 2022.06.13

+ Recent posts