URI URL URN URI Uniform Resource Identifier의 약자로, 리소스를 식별하기 위해 사용되는 식별자 Uniform: 리소스를 식별함에 있어 통일된 방식 사용 Resource: URI로 식별 가능한 모든 형태의 자원 Identifier: 식별자, 다른 항목과 구분하기 위해 필요한 정보 문자열로 구성됨 URI는 리소스의 위치를 이용하거나 이름을 이용해 식별 가능. 둘 다 사용할 수도 있음 URN Uniform Resource Name의 약자로, URI의 일종 리소스에 이름을 부여해 리소스를 식별 URN, 즉 이름만으로는 리소스를 찾을 수 있는 방법이 보편화되지 않음 URL Uniform Resource Locator의 약자로, URI의 일종 리소스에 위치를 부여해 리소스를 식별 URN으로는 리소스를 찾을 수 있는 방법이 없어서, 대부분의 URI는 URL로 사용됨 URL 구조 URL은 다음과 같은 문자열 구조를 가짐

AJAX AJAX Asynchronous Javascript And XML의 약자 Javascript와 XML을 이용해 비동기식으로 서버와 통신하는 기법 XML 뿐만 아니라 JSON을 활용한 통신도 가능 XMLHttpRequest라는 객체를 이용해 브라우저에서는 AJAX 요청을 보내고 받음 JQuery를 사용하면 AJAX를 쉽게 사용 가능 서버에서 데이터만 받아오면 되기 때문에 서버를 기다리지 않고 처리 가능 CORS 정책 위반, 자바스크립트가 안 되면 아무것도 보여줄 수 없는 등의 단점도 존재 References https://devyj.tistory.com/1 https://azderica.github.io/00-javascript-ajax/

XMLHttpRequest XMLHttpRequest 자바스크립트에서 서버에서 데이터를 가져오기 위해 사용되는 자바스크립트 객체. AJAX에서 주로 사용 서버에서 화면의 새로고침 없이 데이터를 가져올 수 있음 이름에서 보이는 것과 달리 XML 뿐만 아니라 모든 형태의 데이터를 가져올 수 있음 개발자가 사용하는 경우는 드물며, 브라우저에 내장되어 있음 최근에는 Fetch, Axios등을 이용해 서버와의 통신을 구현 References https://developer.mozilla.org/ko/docs/Web/API/XMLHttpRequest http://www.tcpschool.com/ajax/ajax_server_xmlhttprequest https://7942yongdae.tistory.com/67

HTTPS HTTPS HTTP는 암호화되지 않은 평문을 전송하기 때문에 보안에 매우 취약 HTTPS란 HTTP에 데이터 암호화를 추가한 프로토콜. SSL 위에서 HTTP 메시지를 주고 받음 구글은 HTTPS를 사용하는 사이트에 SEO 가산점을 줌 443번 포트를 사용하며, 80% 이상의 웹사이트에서 사용 References https://mangkyu.tistory.com/98 https://devjem.tistory.com/3

HTTP HTTP Hyperlink를 포함한 문서인 hypertext를 전송하기 위한 application layer 프로토콜 클라이언트 - 서버 모델에서 요청-응답 프로토콜로서 사용됨 클라이언트가 HTTP 요청 메시지를 서버에 제출하면, 서버는 HTTP 응답 메시지를 클라이언트에 반환 Well known port인 80번 포트를 이용함 여러 요청이 지속되는 동안 사용자의 상태를 저장하지 않는 stateless 프로토콜 사용자 세션을 관리해야 할 때는 http 쿠키 등을 이용 HTTP 버전별 기능 HTTP/0.9 1991년에 발표된 최초의 버전 GET 방식으로 HTML 문서만 가져올 수 있었음 서버가 응답한 후 TCP/IP 연결이 끊김.

OAuth OAuth 사용자가 비밀번호를 입력하지 않고 어떤 웹 사이트 / 애플리케이션에게 다른 웹사이트의 정보 접근 권한을 부여하는 표준 ex) 프로그래머스는 github로 로그인을 통해 사용자의 정보를 github로부터 가져 옴 접근 권한을 위임하는 행위 1.0a 버전과 2.0 버전 존재 OAuth 1.0a 가장 최초의 oauth 버전은 1.0이나, 세션 고정 공격을 회피하기 위해 1.0a 버전으로 수정되었다고 함 Access token 이 만료되지 않는 문제 및 웹이 아니면 사용이 힘듦 또한 암호화를 직접 수행해야 하므로 번거로움 OAuth 1.

Token based authentication & JWT Token 기반 인증 방식 클라이언트가 서버에 접속하면, 서버가 클라이언트에게 서명된 토큰을 발급해 주는 방식 클라이언트는 토큰을 쿠키 혹은 로컬 스토리지등에 저장하고, 이후 서버에 요청할 때마다 토큰을 함께 전송 서버는 토큰을 검증하고 요청에 응답 Session과 달리 서버에 정보를 저장하는 것이 아니라 토큰에 정보를 저장함 Token 사용의 장점 세션과 비교해 추가적인 서버 저장소 관리가 필요하지 않고, 사용자 수가 많아진다고 서버 부담이 늘지 않음 OAuth 등에서도 사용한 만큼 확장성이 높음 모바일 앱에서 사용이 용이 JWT JSON 데이터를 Base64 URL-safe 인코딩해서 직렬화한 토큰 JSON 데이터는 Header, Payload, Signature 세 부분으로 구성됨 각 부분은 .

Authentication Authorization Authentication 개체(사용자)의 신원을 확인하는 행위; 인증이라고 함 ID, password를 입력하는 행위가 가장 대표적인 인증 다음과 같은 방법들을 통해 인증 HTTP 헤더: 사용자 정보를 HTTP 헤더에 담아 인증을 수행, 보안이 굉장히 낮음 세션 + 쿠키: 세션과 쿠키를 활용해 인증 토큰: JWT와 같은 토큰을 이용한 인증 OAuth Authorization 개체(사용자)의 보내는 요청을 실행할 수 있는 지 확인하는 행위; 인가라고 함 인가를 받은 사용자는 리소스 등에 접근 권한을 가짐 JWT를 통해 인가를 수행하는 예시 인증을 통해 access token 생성하고 유저에게 전달 유저가 access token을 이용해 서버에 요청을 전송 서버는 access token을 이용해 user id를 얻음 User id를 통해 해당 사용자가 권한을 가지고 있는지 확인하고 요청을 처리 혹은 반려 인증과 인가 사용자가 인증되면, 사용자에 대한 인가도 같이 수행 가능 그러나 인가를 받았다고 해서 인증을 할 수 있는 것은 아님 References https://yuna-library.

Session Cookie Cookie 서버에서 사용자의 컴퓨터에 저장한 데이터 파일. 브라우저를 통해 저장 및 사용이 이루어짐 key-value 형태로 구성된 데이터이며, 서버와 브라우저는 HTTP 메시지 안에 이 쿠키를 담아 주고 받음 서버가 브라우저에 응답할 때 Set-Cookie라는 응답 헤더의 항목에 쿠키를 넣어서 전달해 줌 브라우저는 해당 쿠키를 일정 기간동안 저장함 만약 별도의 유효기간을 명시하지 않았다면 브라우저가 닫힐 때 사라짐 Expires 혹은 Max-age 속성을 명시하면 해당 기간동안 쿠키가 유지됨 브라우저는 서버에 요청을 보낼 때 Cookie 항목에 쿠키를 동봉해 전송 “이 창을 오늘 더 이상 보지 않음” 등이 쿠키 사용 예시 Cookie의 한계 쉽게 지워지므로 중요한 데이터를 담기에는 부적합 변조 및 도난되기 쉬움 좀비 쿠키 등 악의적인 공격의 수단으로 이용될 수 있음 Session 클라이언트가 서버에 접속한 상태 및 관련 정보를 세션이라고 함 (🚫) 세션을 이용한다면 정보를 사용자의 컴퓨터가 아닌 서버에 저장함 각 클라이언트가 생성한 세션은 세션 ID라는 고유의 값을 가지고, 이 값을 클라이언트에 쿠키 형태로 넘겨 줌 Session과 Cookie 쿠키와 세션은 서로 반대의 개념이 아닌, 상호 보완적인 개념.

Seperate Front Back 프론트엔드와 백엔드를 분리하는 이유 확장 및 기술 변경이 쉬움 웹 애플리케이션이 일체형으로 구성되어 되어 있다면 새로운 기능을 확장하거나, 기술 및 언어를 변경하기 위해 전체를 다 변경해야 함 프론트와 백이 분리되어 있다면, 백엔드를 확장하거나 기술 변경을 위해 프론트엔드를 건드릴 필요가 없음 여러 플랫폼에서 API 사용 가능 백엔드 서버가 API를 제공하는 형태가 되면, 여러 플랫폼(웹, IOS, AOS)에서 자유롭게 API를 통해 데이터를 가져와 사용자에게 보여줄 수 있음 서버 부담 감소 일체형 웹 서버는 직접 HTML을 렌더링해서 서버에 보내줘야 하므로, view의 기능을 서버에서 수행하기 때문에 부담이 심함 프론트와 백이 분리되어 있는 경우 백엔드는 관련 데이터만 보내 주면 프론트엔드에서 렌더링을 수행하게 됨 큰 프로젝트에서 효과적 웹 애플리케이션의 크기가 커질 수록 일체형 웹은 개발이 복잡해짐 큰 프로젝트는 프론트엔드 팀과 백엔드 팀을 나눠 각 팀별로 개발을 수행하면 됨 버그가 어디서 발생했는지 찾기 쉬움 코드 최적화가 더 빨리 됨 주의사항 프로젝트가 작은 경우 모놀리식 아키텍쳐(일체형)가 더 도움이 될 수도 있음 서로 다른 환경에서 다른 언어 및 기술을 사용해 개발하기 때문에 혼자 개발하는 경우에는 힘들 수 있음 References https://velog.