URL : 통일된 웹 자원의 위치 지정방법 (Rest API 를 이용한다)
URL의 기본구조는 다음과 같다
scheme/host/request URL/query
<scheme>://[<username>:<password>@]<host>[:<port>]<Request-URI>[?<query>#<fragment>] (조금 더 자세히)
scheme - https/http/ftp/file (프로토콜을 의미한다)
host - domain name (naver.com 등) host는 필수고 [] 안에 옵션을 붙일 수 있다.[<~~>:<~~>@] 이런식.
(Server와 같다)
requestURL - 경로 (/project/to) - 경로를 정하는 정답은 없는데, large->small이 편하다..
query,option이 마지막에 들어온다. ex) "?userWorflowClass~~~"
HTTP :
웹 자원 위치에 접근하는 프로토콜
HyperText를 클라이언트와 서버 사이에 주고받을 수 있게 해주는 프로토콜
조금 더 쉽게 생각하면 TCP/IP 위에서 사용되는 TextBase 프로토콜이다.(사람이 눈으로 보고 이해가능)
프로토콜 구조
요청의 구성
<Method> <Request URI> <Version>
<Header>
<Body>
ex) GET </welcome.html> <HTTP/1.1> < 메쏘드> <'req'> <'version'>
Method의 종류는 다음과 같다
GET, POST, HEAD, OPTIONS, PUT, DELETE, TRACE
이중 자주 사용되는 메소드는 GET, POST, PUT 이다.
Request URI : 웹 서비스에서 루트를 기준으로 파일을 찾는것과 비슷하다
Version : HTTP/<'Major version'>.<'Minor version'>으로 구성된다.
응답의 구성
<Version> <Status Code> <Reason Phrase>
<Header>
<Body>
Version : 0.9, 1.0, 1.1, 2.0
Status Code : 간략하게 정리하면 다음과 같고, 면접을 위해서는 더 세세히 알아야 한다.
1xx: 정보 제공
2xx: 성공
3xx: 리다이렉션
4xx: 클라이언트의 오류
5xx: 서버의 오류
Reason Phrase(거절 사유)
200 OK
401 Unathorized
404 Not Found
Body(or Entity) -> 실제 내용을 의미하며 다양하다 (이미지, HTML, 비디오 등)
이미지,비디오 (바이너리) -> 텍스트 -> 전송
GET vs POST (예제 실습)
Get - 리소스를 요청하기 위한 메소드로 리소스(파일)을 가져오기 위해 사용된다
Post - 서버에 입력 데이터를 전송하기 위한 메소드로 서버에 데이터 전송을 위해 주로 사용된다. 주로 HTML 폼을 사용하기 위해 많이 사용됨
-차이점-
요청주소 :
GET - /welcome.html?name=TEST-NAME&content=TEST-CONTENT&send=send
POST - /welcome.html
헤더 :
GET - Content-Type, Content-Length 헤더 없음.
POST - Content-Type: application/x-www-form-urlencoded, Content-Length: 45
GET은 전송 데이터 길이에 제한이 있다
(만들어진 목적이 다르다)
General Headers, Request Headers, Response Headers, Entity Headers
헤더 - 짧을수도 길수도 있다. 그리고 [반드시 들어가야하는것 / 옵션] 등 다양하게 구성할 수 있다.
General Headers : 클라이언트와 서버 양쪽에서 사용
Request Headers : 클라이언트에서 사용 (Accept, Cookie)
Response Headers : 서버에서 사용 (Server, Set-Cookie)
Entity Headers : 엔티티 본문에 대한 헤더 (Location, Content-Length, Content-Type)
인증, 쿠키, 세션
Redirection인 경우 제외하면 연결 후 유지를 안함.
연결-send-connection 종료.
Send 후로는 서버에 붙일 필요가 없다.
쿠키(Cookie)
서버가 클라이언트에 붙인 일종의 스티커
웹 서비스를 할때 클라이언트의 상태를 가져야 할 필요가 생김 (로그인 등)
일종의 sticker 역할로 클라이언트 상태 기억
서버가 클라이언트에게 쿠키를 세팅 요청(set-cookie) 하면, 클라이언트는 이후 서버에게 보내는 요청 헤더에 쿠키를 표시해서 전송한다.
서버 -> 클라이언트 쿠키 세팅 요청(스티커 붙임)
클라이언트 -> 서버 쿠키 전달
종류 -
세션쿠키 - 브라우저 쓰는 동안만 지속
지속쿠키 - 브라우저 종료해도 유지되는 쿠키
Set-Cookie
용도 : 사용 세션 관리, 개인화, 사용자 추적
Session : 사용자 접속 시점에 임의의 세션ID를 발급한다.(세션 ID만으로는 사용자 개인 정보를 몰라야 한다)
temporary -> session cookie.
만약 로그인 하고 이름을 바꾼다? -> 새로운 키 생성해서 그것으로 접속한다.
HTTPS (Protocol layers -> HTTP over SSL/TLS)
SSL/TLS (주로 사용)
HTTPS에서 사용하는 알고리즘
-대칭키, 비대칭키, 키 교환- 알고리즘, 인증서, 인증기관
대칭키 알고리즘 - 암호화에 사용하는 키와 복호화에 사용하는 키가 같은 알고리즘
대칭키 문제점 - 잘못하여 대칭키가 복사되면 누구나 볼 수 있다
대칭키의 종류 - DES, AES(더 최신)
일반적으로 대부분 대칭키 알고리즘 사용
암복호화 성능이 좋다
키 교환 알고리즘 - 키를 만들어서 (실시간) 전송한다
키 합의(DH) - 키 전송(RSA)
보안적으로 안전하다 : 저장된 키가 해킹당해도 매번 새로운 키를 생성하기 때문에 괜찮다.
비대칭키 암호화 알고리즘 - 암복호화에 사용하는 키가 서로 다른 알고리즘
공개키, 개인키
공개키로 암호화 -> 개인키로 품
개인키로 암호화 -> 공개키로 품
ex) RSA