네이티브 애플리케이션 : iOS, Android, Windows같은 특정 실행환경에 종속되어 실행되는 애플리케이션
장점
-웹 애플리케이션보다 빠르다
-기기의 시스템, 리소스 등에 접근이 용이하다
-인터넷없이 사용 가능하다
-앱스토어의 승인을 받아야하기 때문에 웹 애플리케이션에 비해 안전하다
단점
-멀티 플랫폼 개발 등 개발비가 더 들어간다
-앱스토어의 승인을 받기가 힘들고 비용도 발생하며 빠른 업데이트가 어렵다.
웹 애플리케이션 : 웹 브라우저를 통해 접근이 가능한 애플리케이션
장점
-별도 설치가 필요없다
-유지관리가 쉽다
-네이티브 애플리케이션에 비해 만들기 간편하다
-앱스토어 승인이 필요없다
단점
-인터넷 연결이 필수적이다
-네이티브 애플리케이션에 비해 속도가 느리다
-앱스토어에 올라가지 않기 때문에 사용자 접근성이 떨어진다
LANLocal Area Network : 좁은 범위에서 연결된 네트워크. 빠른 데이터 전송 속도와 낮은 지연시간을 갖지만 거리 제한이 있다.
WANWide Area Network : 넓은 지역을 커버할 수 있지만 데이터 전송 속도가 느리고 비용이 많이 발생한다.
인터네트워킹 : 여러 개의 네트워크를 연결하여 확장하는 방식.
프로토콜 : 공통된 약속
IP Internet Protocol
LAN 네트워크 내부에서는 Private IP 주소를, 인터넷에서는 Public IP 주소를 사용한다.
IP주소는 어떤 네트워크인지 확인할 수 있는 네트워크부와 네트워크 안의 특정 컴퓨터를 지칭하는 호스트부로 나뉜다. 호스트부는 0과 255를 제외한 번호로 할당이 가능하다.
네트워크부가 어디까지인지 나타내는 것은 서브넷 마스크
IP프로토콜은 송수신 상대의 상태 파악이 불가능한 비연결성 문제, 중간에 패킷이 사라져도 알 수 있는 방법이 없다는 점, 의도한 순서대로 데이터가 도착하지 않을 수도 있다는 등의 한계가 있다.
MAC 주소 : 각 네트워크 기기가 갖는 고유 시리얼. IP 주소만으로는 통신이 불가능하다. MAC 주소와 IP주소를 조합해야 통신이 가능하다. 이더넷에서 송수신 상대를 특정하고자 사용한다.
패킷packet : 네트워크에서 데이터는 패킷이라는 작은 단위로 쪼갠 뒤 이루어진다. 패킷에는 보내는 곳, 목적지, 어떤 데이터의 몇 번째 데이터인지를 저장하는 헤더와 페이로드로 구성되어 있어, 데이터가 분할되어 전송되더라도 복원이 가능하다.
TCP Transmission Control Protocol : 연결 지향적 프로토콜
3-way handshake, 4-way handshake 등의 방식을 통해 신뢰성 있는 데이터 통신을 설정한다.
전송하는 패킷의 순서가 보장되지만 UDP와 비교해 느리다
3-way handshake : 연결을 초기화할 때 양쪽 모두 송수신이 준비가 되었다는 것을 보장하기 위해 사용한다.
1. 클라이언트가 서버에 접속을 요청하는 SYN 패킷을 보낸다.
2. 서버는 클라이언트에게 요청을 수락하는 ACK와 SYN flag가 설정된 패킷을 보낸다.
3. 클라이언트가 서버에 ACK 발송. 연결이 이루어진다.
4-way handshake : 세션 종료를 위해 수행하는 절차
1. 클라이언트가 FIN 플래그를 전송한다.
2. 서버는 ACK를 보내 확인을 알리고 연결을 종료할 준비를 한다.
3. 연결해지 준비가 완료되면 FIN 플래그를 전송한다.
4. 클라이언트는 ACK를 보내 해지준비를 확인했음을 알린다.
UDP User Datagram Protocol
비연결형 서비스, 데이타그램 지향적 프로토콜
전송, 패킷순서 보장이 되지 않는다. TCP에 비해 단순하며 빠르다.
비디오 재생, DNS 조회 등 시간에 민감한 전송을 위해 사용한다.
그러나 UDP는 handshake 등의 절차를 거치지 않으므로 DDos 공격에 취약하다.
포트 Port : 대상 IP 기기의 특정 애플리케이션connection endpoint를 특정하는 번호
URL Uniform Resource Locator : 서버가 제공하는 환경에 존재하는 파일의 위치
URL의 기본요소는 scheme, hosts, url-path
쿼리나 북마크는 부가요소
https://www.google.com/search?q=java 에서
https:// 는 scheme
www.google.com/ 은 hosts
/search 는 url-path
?q=java 는 query
도메인 이름 domain name
-Registry : 도메인 관리 기관
-Registar : 중개 등록업체
-gTLD generic Top Level Domain : .com .net .org .edu .gov .int .mil .biz .name .info
-ccTLD : .kr .us 등등
.kr의 registry는 한국인터넷진흥원, registar는 가비아, 후이즈 등
DNS Domain Name System : 도메인 네임에서 IP주소로, IP주소에서 도메인 네임으로 변환하는 데이터베이스 시스템
웹 브라우저에 URL을 입력하면 DNS Resolver는
1. 해당 주소의 IP가 캐시에 있는지 확인하고 > 있다면 연결
2. 없다면 Root Server
3. 또 없다면 TLD Server
4. 또 없다면 Domain name server
곧바로 도메인 네임 서버에서 확인하지 않는 이유는, 도메인 네임 서버의 데이터베이스가 너무 방대해서 탐색이 느리기 때문
웹 : 인터넷에서 제공하는 하이퍼텍스트 시스템
2티어 아키텍처(클라이언트-서버 아키텍처) : 리소스가 존재하는 곳(서버)와 리소스를 사용하는 앱(서버)를 분리한 것
3티어 아키텍처 : 2티어 아키텍처 + 데이터베이스
웹 사이트 : 정적 페이지
웹 어플리케이션 : 동적 페이지를 포함. 오늘날 대부분의 웹사이트는 웹 어플리케이션이다.
웹 어플리케이션 3단계 계층 구조
-Presentation Layer : 클라이언트와 직접 접촉. ex. 웹 서버
-Application Layer : Business Layer, Business Logic, Domain Logic
클라이언트의 요청을 받아서 처리, 데이터 접근을 위한 경로를 규격화하는 등의 과정을 수행한다.
-Data access layer : Persistence layer : 데이터 저장소에 접근하여 읽기쓰기 담당
Single Page Application : 서버로부터 새로운 페이지를 불러오지 않고 현재 페이지를 동적으로 다시 작성하는 방식. AJAX, Asynchronous Javascript, XML 등이 사용된다.
Microservice architecture : 한 가지 기능에 집중한 웹 어플리케이션. 각 기능들은 상호 의존적으로 설계되지 않아서 유연성, 개발 속도 등이 좋다
Serverless architecture : 서버나 기타 인프라를 외부의 클라우드 서비스 제공자에게 의탁하는 방식
쿠키 Cookie : 클라이언트에 저장되는 유저의 정보. 주로 로그인 정보, 장바구니 정보를 저장할 때 사용한다.
세션 Session : 쿠키와 비슷하나 저장을 서버에 한다는 차이점이 있다. 세션정보는 쿠키에, 실제 매칭되는 값들은 서버측에서 관리하는 방법이 일반적이다.
SSR Server Side Rendering : 웹 페이지를 서버에서 렌더링한다.
CSR Client Side Rendering : 웹 페이지를 클라이언트 측에서 렌더링한다.
SSR의 장점
-SEO Serach Engine Optimization에 적합하다.
-첫 화면 렌더링이 빠르다.
-사용자와 상화작용이 적은 경우 적절하다
단점
-서버에 자원이용이 집중되기 때문에 유지 비용이 높다
-일부 서드파티 자바스크립트 라이브러리는 SSR이 불가능할 수 있다
-페이지에 접근할 때마다 첫페이지 로딩하는 과정을 다시 반복한다
CSR의 장점
-상호작용이 많은 경우, 빠른 라우팅으로 CSR이 더 적절하다
-첫 화면 렌더링이 느리지만 처음에 모든 정보(html, css, js)를 로딩하기 때문에 이후 다른 페이지 로딩이 빠르다.
단점
-CSR은 빈 html 문서를 가져오기 때문에 SEO에 적합하지 않다
-첫 화면 렌더링이 느리다
CORS Cross-origin regquests : 다른 도메인의 데이터들을 가져올때 cors처리(특정 도메인에 대해 접근 허용)을 하면 데이터를 주고 받을 수 있게 된다.
