• 같은 IP 내에서 2개 이상의 프로세스를 구분할 때 사용
• 패킷 전송 시, 출발지(IP, PORT), 목적지(IP, PORT)를 같이 보내기 때문에 서버에서 응답할 수 있다.

PORT - 할당

• 0 ~ 65535 할당 가능
• 0 ~ 1023 잘 알려진 포트, 사용하지 않는 것이 좋음
  • FTP : 20, 21
  • TELNET : 23
  • HTTP : 80
  • HTTPS : 443

Reference

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/

애플리케이션 계층 - HTTP, FTP

전송 계층 - TCP, UDP

인터넷 계층 - IP

네트워크 인터페이스 계층

TCP 특징

전송 제어 프로토콜(Transmission Control Protocol)

• 연결지향 - TCP 3 way handshake
• 데이터 전달 보증
• 순서 보장
• 신뢰할 수 있는 프로토콜
• 현재는 대부분 사용

TCP 3 way handshake

• 클라이언트에서 먼저 서버에 연결 요청을 한다.
• 서버도 들어온 연결 요청을 받은 뒤, 클라이언트에게 연결 요청을 한다.
• 그러면, 클라이언트는 서버로부터 답변을 받고 서버와 연결된다.
• 연결이 완료되면, 데이터 전송을 할 수 있다.

데이터 전달 보증

• 데이터를 전송하면, 데이터를 잘 받았다는 응답을 보내준다.

순서 보장

• 순서가 올바르지 않으면, 순서가 잘못된 부분부터 다시 보내라고 한다.

위의 3가지 내용이 가능한 이유

• TCP 세그먼트 안에 전송 제어, 순서, 검증 정보 등과 같이 다양한 정보가 존재하기 때문이다.

UDP

사용자 데이터그램 프로토콜(User Datagram protocol)

• 기능이 거의 없음
• 연결 지향 : TCP 3 way handshake X
• 데이터 전달 보증 X
• 순서 보장 X
• 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름
• 정리
  • IP와 거의 동일하나, PORT(어떤 용도로 사용하는지 구분할 때), 체크섬(검증해주는 데이터) 정도만 추가
  • 애플리케이션에서 추가 작업 필요

Reference

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/

인터넷 프로토콜 역할

• 지정한 IP 주소(IP Address)에 데이터 전달
• 패킷(Packet)이라는 통신 단위로 데이터 전달

  IP 패킷 정보

• 출발지 IP, 목적지 IP, 기타, 전송 데이터

IP 프로토콜의 한계

• 비연결성
  • 패킷을 받은 대상이 없거나 서비스 불능 상태여도 패킷 전송
• 비신뢰성
  • 중간에 패킷이 사라지면 보장 X
  • 패킷이 순서대로 온다는 보장 X
• 프로그램 구분
  • 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이라면 구분 X

Reference

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/

문제 풀이 - 해결방법

• BFS를 활용하여 문제를 해결한다.
• 자료구조 Queue를 사용한다.

문제 풀이 - 코드

import java.util.LinkedList;
import java.util.Queue;

class Solution {
    static int[] dx = {1, -1, 0, 0};
    static int[] dy = {0, 0, 1, -1};

    static class Node{
        int x;
        int y;

        public Node(int x, int y){
            this.x = x; 
            this.y = y;
        }
    }

    static Queue<Node> queue = new LinkedList<Node>();
    static boolean[][] isVisited;
    static int size = 0;

    public int[] solution(int m, int n, int[][] picture) {
        int numberOfArea = 0;
        int maxSizeOfOneArea = 0;

        isVisited = new boolean[m][n];

        for(int row = 0; row < m; row++){
            for(int col = 0; col < n; col++){
                if(picture[row][col] != 0 && isVisited[row][col] != true){
                    size = 1;
                    bfs(picture, row, col, m, n);
                    numberOfArea++;

                    if(maxSizeOfOneArea < size){
                        maxSizeOfOneArea = size;
                    }
                }
            }
        }

        int[] answer = new int[2];
        answer[0] = numberOfArea;
        answer[1] = maxSizeOfOneArea;
        return answer;
    }

    static void bfs(int[][] picture, int x, int y, int m, int n)
    {
        queue.add(new Node(x, y));
        isVisited[x][y] = true;

        while(!queue.isEmpty()){
            Node curr = queue.poll();

            for(int dir = 0; dir < 4; dir++){
                int nx = curr.x + dx[dir];
                int ny = curr.y + dy[dir];

                if(0 <= nx && nx < m && 0 <= ny && ny < n){
                    if(picture[nx][ny] == picture[x][y] && isVisited[nx][ny] != true){
                        queue.add(new Node(nx, ny));
                        isVisited[nx][ny] = true;
                        size++;
                    }
                }
            }
        }
    }
}

• Map 인터페이스를 구현한 대표적인 Map 컬렉션
• Map 인터페이스를 상속하고 있기에 Map의 성질을 그대로 가지고 있다.
• Key, Value로 구성된 Entry객체를 저장하는 구조
• Key, Value는 모두 객체
• 값은 중복 저장될 수 있지만, 키는 중복 저장될 수 없다.
• 기존에 저장된 키와 동일한 키로 값을 저장하면 기존의 값은 없어지고 새로운 값으로 대치된다.
• Hashing을 사용하기 때문에 많은 양의 데이터를 검색하는 데 있어서 뛰어난 성능을 보인다.

사용법

• Hashmap Import

    import java.util.HashMap

• 선언

    HashMap<String, String> map1 = new HashMap<String, String>(); // HashMap 생성
    HashMap<String, String> map2 = new HashMap<>(); // new에서 타입 파라미터 생략가능
    HashMap<String, String> map3 = new HashMap<>(map2); // map2의 모든 값을 가진 HashMap 생성
    HashMap<String, String> map4 = new HashMap<>(10); // 초기 용량(capacity) 지정
    HashMap<String, String> map5 = new HashMap<>(10, 0.7f); // 초기 용량(capacity), load factor 지정

• 워킹 디렉토리의 모든 파일은 크게 Tracked와 Untracked로 나뉜다.
• Tracked 파일은 이미 스냅샷에 포함돼 있던 파일
  • Unmodified와 Modified, Staged 상태 중 하나이다.
• 그 외에 나머지 파일들은 Untracked 파일이다.
  • 워킹 디렉토리에 있는 파일 중 스냅샷에도 Staging Area에도 포함되지 않은 파일이다.
• 처음 저장소를 Clone 하면 모든 파일은 Tracked이면서 Unmodified 상태이다.
• 실제로 커밋을 하기 위해서는 이 수정한 파일을 Staged 상태로 만들고, Staged 상태의 파일을 커밋한다.

파일의 상태 확인하기

파일의 상태를 확인하려면 보통 git status 명령을 사용한다.

    $ git status
    On branch master
    Your branch is up-to-date with 'origin/master'.
    nothing to commit, working directory clean

위의 내용은 파일을 하나도 수정하지 않았다는 것을 의미한다.

프로젝트에 README 파일을 만들어보자. 해당 파일은 새로 만든 파일이기 때문에 git status 명령어를 실행하면 'Untracked files'에 들어가 있다.

    $ echo 'My Project' > README
    $ git status
    On branch master
    Your branch is up-to-date with 'origin/master'.
    Untracked files:
      (use "git add <file>..." to include in what will be committed)
        README
    nothing added to commit but untracked files present (use "git add" to track)

해당 파일은 Untracked 상태로, 파일이 Tracked 상태가 되기 전까지는 커밋되지 않는다.

파일을 새로 추적하기

git add 명령으로 파일을 새로 추적할 수 있다.

    $ git add README

후에, git status 명령을 사용하면, README 파일이 Tracked 상태이면서, 커밋에 추가될 Staged 상태라는 것을 확인할 수 있다.

    $ git status
    On branch master
    Your branch is up-to-date with 'origin/master'.
    Changes to be committed:
    (use "git reset HEAD <file>..." to unstage)
        new file:   README

'Changes to be committed'에 들어 있는 파일은 Staged 상태라는 것을 의미한다. 커밋하면, 'git add'를 실행한 시점의 파일이 커밋되어 저장소 히스토리에 남는다.

추가로, git add (files) 명령은 파일 또는 디렉토리의 경로를 아규먼트로 받는다. 디렉토리면 아래에 있는 모든 파일들까지 재귀적으로 추가한다.

Modified 상태의 파일을 Stage하기

CONTRIBUTING.md라는 파일을 수정하고 나서 git status 명령을 다시 실행하면 아래와 같다.

    $ git status
    On branch master
    Your branch is up-to-date with 'origin/master'.
    Changes to be committed:
      (use "git reset HEAD <file>..." to unstage)
        new file:   README
    Changes not staged for commit:
      (use "git add <file>..." to update what will be committed)
      (use "git checkout -- <file>..." to discard changes in working directory)
        modified:   CONTRIBUTING.md

'Changes not staged for commit'는 수정한 파일이 Tracked 상태이지만, 아직 Staged 상태는 아니라는 것을 의미한다. 따라서, git add 명령어를 통해, Staged 상태로 만들어줘야 한다. add의 의미는 프로젝트에 파일을 추가한다기 보다는 다음 커밋에 추가한다고 받아들이는게 좋다.

파일 상태를 짤막하게 확인하기

git status 명령으로 확인하는 내용이 조금 길면, 간단하게 변경 내용을 보여주는 옵션이 있다. git status -s 또는 git status --short 옵션을 주면 된다.

    $ git status -s
    M README
    MM Rakefile
    A  lib/git.rb
    M  lib/simplegit.rb
    ?? LICENSE.txt

아직 추적하지 않은 새 파일 앞에는 ??표시가 붙는다. 왼쪽은 Staging Area, 오른쪽은 Working Tree 상태를 표시한다.

파일 무시하기

어떤 파일은 Git이 관리할 필요가 없다. 보통 로그 파일이나 빌드 시스템이 자동으로 생성한 파일이 그렇다. 그런 파일을 무시하려면, .gitignore 파일을 만들고 그 안에 무시할 파일 패턴을 적는다.

    $ cat .gitignore
    *.[oa]
    *.~

첫번째 라인은 .o 나, .a인 파일을 Git이 무시하라는 것이고, 두번째 라인은 ~로 끝나는 모든 파일을 무시하라는 것이다. o나 a는 각각 빌드 시스템이 만들어내는 오브젝트와 아카이브 파일이고, ~로 끝나는 파일은 Emacs나 VI같은 텍스트 편집기가 임시로 만들어내는 파일이다. .gitignore 파일은 보통 처음에 만들어 두는 것이 편리하다. 그래야 실수로 불필요한 파일을 실수로 커밋하는 일을 방지할 수 있다.

.gitignore 파일에 입력하는 패턴은 아래 규칙을 따른다.

• 아무 것도 없는 라인이나, '#'으로 시작하는 라인은 무시한다.
• 표준 Glob 패턴을 사용한다. 이는 프로젝트 전체에 적용된다.
  • 애스터리스크(*)는 문자가 하나도 없거나 하나 이상을 의미
  • [abc] 는 중괄호 안에 있는 문자 중 하나를 의미한다.
  • 물음표(?) 는 문자 하나를 의미
  • [0-9] 처럼 중괄호 안의 캐릭터 사이에 하이픈(-)을 사용하면 그 캐릭터 사이에 있는 문자 하나를 말한다.
  • 애스터리스크 2개를 사용하여 디렉토리 안의 디렉토리까지 지정할 수 있다.
  • a/**/z 패턴은 a/z, a/b/z, a/b/c/z 디렉토리에 사용할 수 있다.
• 슬래시(/)로 시작하면 하위 디렉토리에 적용되지 않는다.
• 디렉토리는 슬래시(/)를 끝에 사용하는 것으로 표현한다.
• 느낌표(!)로 시작하는 패턴의 파일은 무시하지 않는다.

Staged와 Unstaged 상태의 변경 내용을 보기

어떤 내용이 변경됐는지 살펴보려면 git diff 명령을 사용해야 한다.

    $ git diff
    diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
    index 8ebb991..643e24f 100644
    --- a/CONTRIBUTING.md
    +++ b/CONTRIBUTING.md
    @@ -65,7 +65,8 @@ branch directly, things can get messy.
     Please include a nice description of your changes when you submit your PR;
     if we have to read the whole diff to figure out why you're contributing
     in the first place, you're less likely to get feedback and have your change
    -merged in.
    +merged in. Also, split your changes into comprehensive     chunks if your patch is
    +longer than a dozen lines.
     If you are starting to work on a particular area, feel free to submit a PR
     that highlights your work in progress (and note in the PR title that it's

해당 명령은 워킹 디렉토리에 있는 것과 Staging Area에 있는 것을 비교한다. 만약 커밋하려고 Staging Area에 넣은 파일의 변경 부분을 보고 싶으면, git diff --staged 옵션을 사용한다. 해당 명령은 저장소에 커밋한 것과 Staging Area에 있는 것을 비교한다.

주의해야할 점 git diff 명령은 마지막으로 커밋한 후에 수정한 것들 전부를 보여주지는 않는다. git diff는 Unstaged 상태인 것들만 보여준다. 수정한 파일을 모두 Staging Area에 넣었다면 git diff 명령은 아무것도 출력하지 않는다.

변경사항 커밋하기

Unstaged 상태의 파일은 커밋되지 않는다는 것을 기억해야 한다.

    $ git commit

메세지를 인라인으로 첨부할 수도 있다.

    $ git commit -m "hi, my name is noah"

Staging Area 생략하기

git commit 명령을 실행할 때, -a 옵션을 추가하면, Git은 Tracked 상태의 파일을 자동으로 Staging Area에 넣는다. 그래서 git add 명령을 실행하는 수고를 덜 수 있다.

    $ git commit -a -m "added new brackmarks"

파일 삭제하기

Git에서 파일을 제거하려면 git rm 명령으로 Tracked 상태의 파일을 삭제한 후에(정확하게는 Staging Area에서 삭제하는 것) 커밋해야 한다. 해당 명령은 워킹 디렉토리에 있는 파일도 삭제하기 때문에 실제로 파일도 지워진다. Git 명령을 사용하지 않고 단순히 워킹 디렉토리에서 파일을 삭제하고 git status 명령으로 상태를 확인하면, Git은 현재 'Changes not staged for commit'(즉, Unstaged 상태)라고 표시해준다.

    $ git rm test1.txt

파일 이름 변경하기

Git은 다른 VCS 시스템과는 달리 파일 이름의 변경이나 파일의 이동을 명시적으로 관리하지 않는다. 다시 말해서 파일 이름이 변경됐다는 별도의 정보를 저장하지 않는다. Git은 똑똑해서 굳이 파일 이름이 변경되었다는 것을 추적하지 않아도 아는 방법이 있다.

    $ git mv file_from file_to

git mv 명령은 아래 명령어를 수행한 것과 완전 동일하다.

    $ mv README.md README
    $ git rm README.md
    $ git add README

참고자료

Git - 수정하고 저장소에 저장하기

• 아직 버전관리를 하지 않은 로컬 디렉토리 하나를 선택해서 Git 저장소를 적용하는 방법
• 다른 어딘가에서 Git 저장소를 Clone 하는 방법

기존 디렉토리를 Git 저장소로 만들기

버전관리를 하지 아니하는 기존 프로젝트를 Git으로 관리하고 싶은 경우 우선 프로젝트의 디렉토리로 이동한다. Windows :

    $ cd /c/user/noah_project

그리고 아래와 같은 명령을 실행한다.

    $ git init

해당 명령은 .git 이라는 하위 디렉토리를 만든다. 해당 디렉토리에는 저장소에 필요한 뼈대 파일이 들어 있다.

아래의 명령어를 통해, 저장소에 파일을 추가하고 커밋할 수 있다.

    $ git add *.c
    $ git add LICENSE
    $ git commit -m 'initial project version'

기존 저장소를 Clone하기

• 다른 프로젝트에 참여하려거나 Git 저장소를 복사하고 싶을 때, git clone 명령을 사용한다.
• 이미 Subversion 같은 VCS에 익숙한 사용자에게는 'checkout'이 아니라 'clone'이라는 점이 도드라져 보일 것이다.
• Git이 Subversion과 다른 가장 큰 차이점은 서버에 있는 거의 모든 데이터를 복사한다는 것이다.
• 프로젝트 히스토리를 전부 받아온다.
• 실제로 서버의 디스크가 망가져도 클라이언트 저장소 중에서 아무거나 하나 가져다가 복구하면 된다.

아래의 명령어를 통해, 저장소를 Clone한다.

    $ git clone https://github.com/libgit2/libgit2

해당 명령은 'libgit2' 라는 디렉토리를 만들고 그 안에 .git 디렉토리를 만든다. 그 후, 저장소의 데이터를 모두 가져와서 자동으로 가장 최신 버전을 Checkout 해 놓는다.

아래의 명령어는 저장소는 다른 디렉토리 이름으로 Clone할 수 있다.

    $ git clone https://github.com/libgit2/libgit2 mylibgit

Git은 다양한 프로토콜을 지원한다. https / git / ssh

참고자료

Git 저장소 만들기

Git은 이 설정에 따라 동작한다. 이때 사용하는 설정 파일은 세 가지나 된다.

/etc/gitconfig

• 시스템의 모든 사용자와 모든 저장소에 적용되는 설정이다.
• git config --system 옵션으로 해당 파일을 읽고 쓸 수 있다.
• 해당 파일은 시스템 전체 설정파일이기 때문에 수정하려면 시스템의 관리자 권한이 필요하다.

~/.gitconfig, ~/.config/git/config

• 특정 사용자(즉, 현재 사용자)에게만 적용되는 설정이다.
• git config --global 옵션으로 이 파일을 읽고 쓸 수 있다.
• 특정 사용자의 모든 저장소 설정에 적용된다.

.git/config

• 해당 파일은 Git 디렉토리에 있고, 특정 저장소(혹은 현재 작업 중인 프로젝트)에만 적용된다.
• git config --local 옵션을 사용하면 해당 파일을 사용하도록 지정할 수 있다.
• 하지만 기본적으로 이 옵션이 적용되어 있다.

우선순위

각 설정은 역순으로 우선시 된다. 따라서, .git/config가 /etc/gitconfig 보다 우선하다.

사용자 정보

• Git을 설치하고 나서 가장 먼저 해야하는 것은 사용자 이름과 이메일 주소를 설정하는 것이다.
• Git은 커밋할 때마다 이 정보를 사용한다. 한 번 커밋한 후에는 정보를 변경할 수 없다.

    $ git config --global user.name "Noah"
    $ git config --global user.email noah@kakao.com

• global 옵션으로 설정하는 것은 딱 한 번만 하면 된다.
• 해당 시스템에서 해당 사용자가 사용할 때는 이 정보를 사용한다.
• 프로젝트마다 다른 이름과 이메일 주소를 사용하고 싶으면, --global 옵션을 빼고 명령을 실행한다.

편집기

• 사용자 정보를 설정하고 나면 Git에서 사용할 텍스트 편집기를 고른다.
• Git은 시스템의 기본 편집기를 사용한다.
• 하지만, Emacs 같은 다른 텍스트 편집기를 사용할 수 있고 아래와 같이 실행하면 된다.

    $ git config --global core.editor emacs

• 윈도우 사용자라면 다른 텍스트 편집기를 사용할 수 있다. 실행파일의 전체 경로를 설정해주면 된다.
• 실행파일의 전체 경로는 사용하는 편집기에 따라 다르다.
• 윈도우 환경에서 많이 사용되는 Notepad 편집기의 경우 주로 32비트 버전을 사용하게 된다.
• 현재 기준으로 64비트 버전을 사용하면 동작하지 않는 플러그인이 많다.

설정확인

• 명령을 실행하면 설정한 모든 것을 보여주어 바로 확인할 수 있다.

    $ git config --list

• Git은 같은 키를 여러 파일에서 읽기 때문에 같은 키가 여러 개 있을 수도 있다.
• 그러면 Git은 나중 값을 사용한다.
• git config key 명령으로 Git이 특정 Key에 대해 어떤 값을 사용하는지 확인할 수 있다.

파일 변화를 시간에 따라 기록했다가 나중에 특정 시점의 버전을 다시 꺼내올 수 있는 시스템

로컬 버전 관리

아주 간단한 데이터베이스를 사용하여 파일의 변경 정보를 관리하는 방법으로, 대표적인 VCS 도구는 RCS(Revision Control System)이 있다.

RCS(Revision Control System)

기본적으로 Patch Set(파일에서 변경되는 부분)을 관리한다. Patch Set은 특별한 형식의 파일로 저장한다. 그리고 일련의 Patch Set을 적용해서 모든 파일을 특정 시점으로 되돌릴 수 있다.

중앙집중식 버전 관리(CVCS)

다른 개발자와 함께 작업해야 할 때, 생기는 문제를 해결하기 위해 개발된 버전 관리 시스템 CVS, Subversion, Perfocre 같은 시스템은 파일을 관리하는 서버가 별도로 있고 클라이언트는 중앙 서버에서 파일을 받아서 사용한다.

로컬 버전 관리 VS 중앙집중식 버전 관리

중앙집중식 버전 관리의 장점

• 누가 무엇을 하고 있는지 알 수 있다.
• 모든 클라이언트의 로컬 데이터베이스를 관리하는 것보다 VCS 하나를 관리하기가 훨씬 쉽다.

  중앙집중식 버전 관리의 단점

• 중앙 서버에서 문제가 발생하면, 문제를 해결하기 전까지 다른 사람과 협업할 수 없고 사람들이 하는 일을 백업할 방법도 없다.
• 중앙 데이터베이스가 있는 하드디스크에 문제가 생기면 프로젝트의 모든 히스토리를 잃는다.

분산 버전 관리 시스템

• Git, Mecurial, Bazaar, Darcs 같은 DVCS에서의 클라이언트는 단순히 파일의 마지막 스냅샷을 체크아웃하지 않는다.
• 저장소를 히스토리와 더불어 전부 복제한다.
• 서버에 문제가 생기면 해당 복제물로 다시 작업을 할 수 있다.
• 대부분의 DVCS 환경에서는 리모트 저장소가 존재한다. 따라서, 동시에 다양한 그룹과 다양한 방법으로 협업할 수 있다.
• 계층 모델 같은 중앙집중식 시스템으로는 할 수 없는 워크플로를 다양하게 사용할 수 있다.

참고페이지

Git - 시작하기

데이터가 로컬 데이터베이스에 안전하게 저장됐다는 것을 의미

Modified

수정한 파일을 아직 로컬 데이터베이스에 커밋하지 않은 것을 말한다.

Staged

현재 수정한 파일을 곧 커밋할 것이라고 표시한 상태를 의미한다.

git directory

프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳을 말한다. 해당 디렉토리가 Git의 핵심이다. 다른 컴퓨터에 있는 저장소를 Clone할 때, Git 디렉토리가 만들어진다.

Working Tree(Working Directory)

프로젝트의 특정 버전을 체크아웃한 것이다. Git 디렉토리는 지금 작업하는 디스크에 있고 그 디렉토리 안에 압축된 데이터베이스에서 파일을 가져와서 워킹 트리를 만든다.

Staging Area

Git 디렉토리에 있으며, 단순한 파일이고 곧 커밋할 파일에 대한 정보를 저장한다. Git에서 기술용어로는 Index''라고 하지만, Staging Area''라는 용어를 써도 상관없다.

Git으로 하는 일은 기본적으로 아래와 같다.

• 워킹 트리에서 파일을 수정한다.
• Staging Area에 파일을 Stage해서 커밋할 스냅샷을 만든다. 모든 파일을 추가할 수도 있고 선택하여 추가할 수도 있다.
• Staging Area에 있는 파일들을 커밋해서 Git 디렉토리에 영구적인 스냅샷으로 저장한다.
• Git 디렉토리에 있는 파일들은 Committed 상태이다.
• 파일을 수정하고 Staging Area에 추가했다면 Staged이다.
• 체크아웃하고 나서 수정했지만, 아직 Staging Area에 추가하지 않았으면 Modified이다.

참고자료

Git - 기초