![[ 얄팍한 코딩사전 - 혼공얄코 ] 14~22강 : 서버와 컴퓨터의 구조](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FbvJcHv%2FbtrUus2To9p%2FgkTFqxHfqagKuktOqp9Jj1%2Fimg.png)
- 앱 종류 정리
| 네이티브앱 | 안드(자바,코틀린) iOS(스위프트, 오브젝C) | HTML, JAVASCRIPT, CSS, 아이오닉 |
| 웹 앱(PWA) | 안드(자바,코틀린) iOS(스위프트, 오브젝C) | 장) 스토어 검수 기다릴 필요가 없음, HTTP(안정적) 단) 앱 모양으로 구현하기가 어려움, 앱스토어 불가, 큰배터리 소모 |
| 하이브리드앱 | HTML, JAVASCRIPT, CSS, 아이오닉 | 장) 스토어 검수 기다릴 필요가 없음, HTTP(안정적) 단) 앱 모양으로 구현하기가 어려움, 앱스토어 불가, 큰배터리 소모 |
- HTTPS를 쓰는 이유 : 서버에 배포할 때 서비스 워커를 활용하기 위함
- SPA F/E 프레임워크(Single Page Application)
- 탄생 배경 : 안드,iOS는 자체 SW와 시스템이 있어, 서버에서 데이터만 전송받으면 됨. 이와 같이, 웹도 주어진 데이터만 전송하면 HTML, JAVASCRPIT로 랜더링을 실현하는 프레임워크
- 용도 : 데이터를 받아올 때 마다, 사이트 내용을 갱신, 컨텐츠 디자인 랜더링(BY JAVASCRPIT)
- VUE라는 특수 형식을 넣어 JAVASCRPIT로 만들어 냄
- 반응
기전기존 서버 반응 기전 사용자가 게시물 주소로 접속 ⇒ 서버가 사용자 행동을 인지 ⇒ DB에서 게시글/좋아요수/댓글 불러옴 ⇒ 데이터들로 CSS/자바스크립트 등으로 작성 ⇒ 브라우저가 게시물을 띄움 현재 서버 반응 기전 Ajax가 HTTP통신으로 데이터를 받아옴 ⇒ 지속적으로 사이트에 변동이 있는 부분만 JAVASCRPIT로 명령
- 프레임워크와 라이브러리 구분
| 프레임워크 | 어떤 것 위에 규칙에 따라 뭔가를 만듦 |
| 라이브러리 | 어떤 것을 가져다가 만듦 - 타프로그램과 링크되기 위한 기능을 묶어둔 집합 파일 - 프레임워크(뼈대)에 붙여서 제작 | |
- 라이브러리 서비스 종류(프레임워크를 제공 ⇒ 안에 라이브러리 제작)
- SPRING, DJANGO, Vue, EXPRESS
- API
- F/E에서 서버에 데이터 요청 등을 받을 때 사용되는 규약(기술이 아닌 형식)
- RESTAPI : HTTP에 요청을 보낼 때, 어떤 URL에 어떤 메소드를 사용할지 정한 규약
- 요청이 어떤 정보, 목적에 의함인지 명시적으로 알 수 있음
- 주요 3형식
- XML : TAG형식(항목명) + 내용을 사용하여 웹을 표현, 주석사용 가능, 스키마로 구조 검증
- 최상단 : 버전 + 인코딩 정보
- TAG형식 = <head>~내용~</head>
- JSON : 자바스크립트의 객체 표기법, 구조화, 코드가 깔끔함, XML 대체제
- 단) 문법 오류에 치명적임
- YAML : 줄바꿈과 태그가 필수 사용, 직관적, 상속 사용 가능
- JSON문법 확인 시 사용되는 프로그램
- XML : TAG형식(항목명) + 내용을 사용하여 웹을 표현, 주석사용 가능, 스키마로 구조 검증
- IP(Internet protocol)
- 컴퓨터가 연결된 네트워크 끝 쪽의 주소, 기기가 인터넷에 접속한 네트워크 상의 위치
-
- 구조 = 공인IP + 사설 IP
- DDNS : 수시로 바뀌는 유동 IP를 감지하여 고정 도메인에 연결함, 소규모 인터넷 운영 실현
- 용도별 IP유형IP(Internet protocol)
- IP유형
서버 고정 IP 일반 가정 주기적으로 IP를 회수하여 인터넷 사용 중인 곳에만 분배하는 유동IP - DNS(Domain Name System)
- 도메인 정보들은 다층적으로 구성된 네트워크 속에서 고분산됨
- 웹사이트 접속 시 내 브라우저가 해당 사이트가 제공하는 서버에 요청하여 웹사이트 데이터를 받아옴
- 이 때, 이를 알기 쉽도록 만든 것 = 도메인
- 이 도메인을 저장하는 것, www뒤에 오는 내용 = DNS
- 서버 접속 기전 = 사이트 접속을 위해 IP주소를 알아내야 함.
- 브라우저가 로컬 DNS에 A사이트 도메인/호스트IP를 소유하는지 조회
- 주소 정보 캐싱 O = 바로 반환
- ROOT DNS가 .com으로 끝나는 도메인 담당 서버의 IP주소를 반환하여 응답
- 로컬DNS 서버가 응답을 .com서버로 보냄
- .com서버가 A사이트 도메인 정보를 가진 DNS서버의 IP주소 반환
- 호스트네임별 IP주소들 저장소에 A사이트 해당 IP주소를 얻어내어 브라우저 반환
- A사이트 도메인 서버에 접속
- DNS 서버=네임 서버
- 도메인을 소유하면, 해당 레벨의 네임 서버를 갖게 됨
- DNS가 고장날 경우, IP직접 접속하는 서버 접근 불가
- 유형
| A record | - 도메인을 서버의 ip로 직연결(빠름) |
| Cname | - 도메인을 서버의 별명으로 연결 |
- 유동IP 서버를 일정하게 연결되는 다른 도메인으로 적음 EX) AWS의 인스턴트에서 사용 |
- HTTPS
- 인터넷 커뮤니케션 유형 중 HTTP의 개선형
- 기능
- 특정 정보를 특정 사이트만 알 수 있도록 암호화 함 (제3자 비공개)
- 비검증된 사이트들을 걸러내는 역할 (개인키로 암호화 된 정보를 공개키로 검증함)
- 키의 유형대칭키 방식 같은 키로 복호화하여 역할이 동일
비대칭키 방식 A,B키를 사용하여 A키는 암호화 역할만 B키는 복호화 역할만 가능
- CA : 안전한 키를 확인하는 공인된 민간기업
- CA를 통한 인증 절차
- 클라(브라우저)가 HANDSHAKE 과정에서 랜덤 데이터를 생성하여 서버로 보냄
- HANDSHAKE : 클라가 서버를 신뢰하지 못하는 상태에서 진행하는 탐색 과정, 특정 사이트의 공개키 정품 여부를 확인
- 서버가 생성한 무작위 데이터 + 인증서를 클라로 전달
- CA 인증서가 CA 개인키로 암호화되고, CA 공개키로 복호화 됨
- CA공개키 = HANDSHAKE로 만들어진 랜덤 데이터를 클라가 혼합하여 임시키를 생성 ⇒ 임시키가 서버의 공개키로 암호화 됨 ⇒ 서버와 클라 양쪽에서 일련의 과정을 통한 대칭키 생성(서버/클라만 확인 가능 공개키)
- 성공 복호화 된 인증서에는 해당 서버의 공개키가 포함됨(단, 공유시 비대칭키를 사용함)
- 클라(브라우저)가 HANDSHAKE 과정에서 랜덤 데이터를 생성하여 서버로 보냄
- HTTP
- 인터넷 커뮤니케이션 유형
- 응답코드
- 100번대 : 요청은 성공적이고 처리 진행중
- 200번대 : 요청 및 처리 성공으로 완벽하게 응답함
- 300번대 : 부분적으로 잘못 입력하였을 때, 유사한 다른 주소로 이동해줌
- 400번대 : 사용자 요청의 문제
- 500번대 : 서버측의 문제
728x90
'관련 도서 및 지식 > 강의 및 인사이트' 카테고리의 다른 글
| [ 아키텍쳐 ] 컴퓨터 아키텍쳐 : CHAPTER 4 ~ CHAPTER 5 (0) | 2023.01.13 |
|---|---|
| [ 아키텍쳐 ] 컴퓨터 아키텍쳐 : 컴퓨터 구조 이해하기 ~ CHAPTER 3 (0) | 2023.01.13 |
| [ 얄팍한 코딩사전 - 혼공얄코 ] 1-13강 : 서버와 언어 (0) | 2022.12.17 |
| JIRA 대시보드 야무지게 활용하기 (JQL 활용법) (2) | 2022.12.16 |
| 그래서 SQL을 왜 써야하는데요? (0) | 2022.12.16 |